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This document and the information contained herein are confidential to and 
the joint property of Honeywell Corporation and the Ultimate Corporation 
for the sole purpose of conducting their business. This document, any copy 
thereof and the information contained herein shall be maintained in 
strictest confidence; shall not be copied in whole or in part except as 
authorized by the employee's manager, and shall not be disclosed or. 
distributed (a) to persons who are not Honeywell or Ultimate employees, or 
(ob) to Honeywell or Ultimate employees for whom such information is not 
necessary in connection with their assigned responsibilities. Upon 
request, or when the employee in possession of this document no longer has 
need for the document for the authorized Honeywell or Ultimate purpose, 
this document and any copies thereof shall be returned to the employee's 
manager. There shall be no exceptions to the terms and conditions set 


forth herein except as authorized in writing by the responsible Honeywell 
or Ultimate Vice President. 


Throughout the text of this document, the term “custom processor" shall be 
interchangeble with the term “Ultimate Processor". | 
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INTRODUCTION 


The thirty-two-bit custom processor is a ten megahertz, thirty-two-bit 
wide, microprogramable firmware engine driven by a one-hundred and 
twenty-eight bit wide control store word and having a blank identity. 


1.1 PURPOSES 


This technical description imparts information which is necessary for 
any who wish to provide the custom processor with a new incarnation. Those 
who attempt personalization of the custom processor need be capable of 
writing and testing microcode. For testing microcode, Custom and Special 


Products offers a Firmware Development Facility which greatly simplifies 
the task (see appendix A). 


1.2 SCOPE 


This document is intended for the prospective microprogrammer. It 
describes the operation of the 32-bit custom processor at the level of an 


experienced coder. Others, such as test technicians, might also find the 
information in section three useful. 


4 


In addition to this section, this document contains four other 
sections and three appendices. 


Section II describes the system environment, an exposure of the 


custom processor capabilities and a brief discussion of each of its major 
areas. 


Section III is a detailed description of each of the fifteen hardware 
areas. 


Section IV is a detailed description of each of the fifteen firmware 
areas. 


Section V is a discussion of internal speed considerations. 


Appendix A contains a description of the Firmware Development Facility 


which is available for the checkout of firmware written for the Custom 
Processor. 


Appendix B contains a description of the Quality Logic Test firmware 
which is available for linking into the custom firmware load and is 


recommended as a means of verifying the integrity of the Custom Processor 
at every system initialization. 
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Appendix C is a description of the Test and Verification routine 
avallable with every incarnation of the Custom Processor. 


1.3 DISCLAIMER 


The firmware dictionary serves as the specification for the custom 


processor. The firmware dictionary shall govern in any disagreement 
between it and this technical description. 


__1.4 REFERENCES 


In order to code firmware to execute on the CUP32, the following 
additional documents may prove useful: 


CUP32 dictionary 
CUP32 logic block diagrams 
for the mother board ..60169259 
for the daughter board 60160249 
RTL6 assembly language manual 


document 
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OPERATIONAL OVERVIEW 


- 


This section describes the system environment into which the 32-bit 
Custom Processor may be connected. The section also gives a first-level 
description of the Custom Processor'’s inner workings. 


2.1 SYSTEM ENVIRONMENT 


The 32 bit Custom Processor is housed in a central subsystem chassis 
(see figure 2-1). This chassis contains an interconnect backplane called 
the Local Bus which allows communication among elements within the central 
subsystem chassis. A minimum of two elements must be installed into the 
central subsystem chassis: namely, a 32-bit Custom Processor and a tri- 
port memory. One port of the tri-port memory connects to a Custom 
Processor on the Local Bus, another port connects via a Custom MEGABUS 
Adapter board to a 32-bit MEGABUS System Bus, and a third port is 
available to connect to a second Custom Processor on the Local Bus. The 
Custom MEGABUS Adapter board physically plugs into the 32-bit System Bus 
and a set of cables connect it to the tri-port memory. The central 
subsystem chassis is designed to accommodate a total of two 32-bit Custom 
Processors and two tri-port memories. In configurations where two 
tri-port memories are installed, each tri-port memory is connected via 
cables to its dedicated Custom MEGABUS Adapter board. The Custom MEGABUS 
Adapter board provides a Custom Processor access to System Bus elements 
including peripheral controllers, communication controllers, central 
memories, and other processing elements (e.g., a Series 6 CPU). 


Each tri-port memory may be configured to contain either two-megabytes 
or four-megabytes of memory. When more than one tri-port memory is 
installed, the total address space is contiguous. Figure 2-2 illustrates 
possible memory configurations which are supported. Note that it is 
possible to connect another complete central subsystem chassis to the 


System Bus for a maximum of four 52-bit Custom Processors and four 
tri-port memories. ; 


The configuration should include at least one LeVel 6 processor, if 
for no other reason than to allow test software to be loaded and executed. 
This is the most effective way of allowing the user to verify the 
integrity of all device and communication controllers. 


Architecturally, the system is strategized to minimize System Bus 
memory —traffic--in support of a processor's instruction stream. In these 
systems memory traffic on the System Bus will service direct memory 
access(DMA) almost exclusively. The only other System Bus traffic will be 
that programmed 1/0 dialogue required to institute and control DMA and 


that interprocessor mailbox dialogue necessary for sharing system 
resources. 
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FIGURE 2-583 
MEMORY ADDRESS ALLOCATION FOR 32-BIT ADDRESS SPACE 
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2.2 INTRODUCTORY DESCRIPTION 


The major block diagram of figure 2-3 is a represextation of the 
Custom Processor. This section is divided into fifteen paragraphs each of 
which discusses the topic ata first level. The discussions in sections 
three and four are similarly subdivided allowin the reader quick 
reference to greater hardware detail (section three) or greater firmware 
detail (section four). The fifteen sections are listed below, each with 
their associated block diagram identifier: 


; - I. the ralu 
II. the aram 
III. the d bus 
IV. the s bus 
V. the z bus 
VI. the Local Bus 
VII. flags 
VIII. shifter 
IX. indicators 
X. op code registers 
XI. other registers 
XII. the clock 
XIII. the stack 
XIV. the next address generator 
XV. availability 
2.2.1 the ralu (see block diagram identifier I) 


The register file and alu is comprised of eight 2981 bit slice 
chips constituting a thirty-two-bit alu, a sixteen-location dual-ported 
random—- access memory anda bit shifter (32 or 64 bits wide). Operations 
inside the alu occur at nearly a ten megahertz rate. The ralu receives 


external thirty-two-bit data from the dbus and transmits thirty-two-bit 
results to the zbus. 


2.2.2 the aram (see block diagram identifier ITI) 


The auxiliary random access memory is a single-ported 
4996-location memory. Each location contains thirty-two bits. The memory 
may be addressed in any one of seven different ways. Its data is read onto 
the sbus. Data written into the aram is taken from the sbus. Writing of 
the aram is byte partitioned; that is, any combination of 1, 2, 3, or 4 
bytes may be “copied” from the sbus into the addressed aram location. 
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2.2.5 the dbus (see block diagram identifier III) 


The dbus is the place where all roads lead. It is a thirty-two 
bit bus which receives data from the sbus, the zbus, the pbus and numerous 
other secondary sources. It may deliver its wealth to the ralu, the output 
register, and to the zbus. It has byte partitioning capabilities; e.g., it 
may take a byte of the aram for its upper eight bits, an h register byte 
for its next eight bits, a literal for its next eight bits, and a bunch of 
zeros for its last eight bits. 


~ 2.2.4 the sbus (see block diagram identifier IV) 


The sbus receives and provides aram ‘data. It receives and 
provides data for the three Local Bus address registers. It has the unique 
Capability of receiving and reflecting two of its sources during the same 
firmware step by virtue of a time-multiplexing mechanism. 


2.2.5 the zbus (see block diagram identifier V) 


it the dbus is where all roads lead and the sbus is 
hermaphroditic, the zbus is totally colorless. Indeed, it is a 
journeyperson bus, capable of receiving data from the outside world (the 
memory subsystem), receiving ralu revelations and sending all this to the 
v register, and/or to the dbus, and/or to the sbus via the nibble shifter. 


2.2.6 the Local Bus (see block diagram identifier VI) 


The Local Bus is the area of the processor responsible for 
communicating with the memory subsystem and through it, via the System 
Bus, to all other system elements; e.g., a Series 6 processor or a Series 
6 controller. The Local Bus area contains, along with the interface 
circuits required to carry on a dialogue upon the Local Bus, an eight-byte 
look-ahead procedure buffer and two four-byte data buffers. The two data 
buffers receive information from memory to be deposited onto the zbus. The 
look-ahead procedure buffer is organized to supply one or two bytes to the 
op register and/or the dbus and automatically replentish the prefectch 
buffer as bytes are consumed. 


2.2.7 flags (see block diagram identifier VII) 


The Custom Processor contains twenty-four firmware settable and 
testable flops. Some have hardware dedicated functions (e.g., processor 
off-line); others have more sophisticated firmware sequence control 
characteristics (e.g., they may participate in sixteen-way "splatters"). 


2.2.8 shifter (see block diagram identifier VIII) 


The shifter is a nibble rotator connected between the zbus and — 
the sbus. All_eight -possible 4 bit shift distances are supported e.g., 
shift left four nibbles, shift right four nibbles and “word swap" are 
a three equal operations. 


2.2.9 indicators (see block diagram identifier IX) 


Indicators are storage elements which remember some property of 
the results obtained in one firmware step so that they may affect the 
firmware sequence later on. There are arithmetic indicators like "zero" 
and “carry” which are provided at any byte partition and there are more 
specialized indicators like the leading-zero detector. Many have the 
ability to participate in “splatters” which permits up to 17-way firmware 
branches. 
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2.2.19 op registers (see block diagram identifier X) 


The op registers permit capturing interesting nibbles of the 
procedure stream for future reference. The storage mechanisms involved may 
also receive nibbles from the sbus; they contribute to aram addressing, 
they may be incremented or decremented, they may be tested for crossing 
the zero boundary, and they may participate in 17 way branches. 


2.2.11 other registers (see block diagram identifier XI) 


Many other registers provide strategically located storage for 
information. Address registers for data and procedure fetches, which can 
be incremented or decremented, are loaded from the sbus and communicate 
their content to the memory subsystem. The output data register is loaded 
from the dbus and communicates its content to the memory subsytem. The v 
register is connected bidirectionally to the zbus and is a convenient 
stopover for zbus data. The h register, one of the byte partitionable 


sources to the dbus, and the accounting timer are also loaded from the 
sbus. 


2.2.12 clock (see block diagram identifier XII) 


The clock has a maximum frequency of nearly ten megahertz. It is 
an asynchronous mechanism whose speed for each step is selected by the 
firmware assembler. The clock is structured to wait before starting the 
next step (stall) if the coder wishes, implicitly or explicitly, to 
postpone its start until an external event occurs (such as receiving 
previously requested memory subsystem data). 


2.2.13 the stack (see block diagram identifier XIII) 


The return stack is a mechanism which simplifies the use of 
subroutines. It contains seventeen levels. Absolute or relative addresses 


may be “pushed” onto the stack. Unconditional, conditional and masked 
returns are provided. 


2.2.14 the next address generator (see block diagram identifier XIV) 


The next address generator is a particularly flexible element in 
that it eliminates the need for numeric sequentiality in the execution of 
firmware steps. The next address may be any one of the 16384 locations 
provided. The destination may be specified as a "go-to” or it may be 
chosen from a pair of addresses dependent upon one of seventy-two test 
conditions. It may instead be chosen among sixteen locations dependent 
upon some group of four indicators (six groups are provided) or the 
destination may be a seventeenth location dependent upon one of the 
seventy-two test conditions. Then again, it may be chosen among one of 256 
locations dependent upon a byte of the procedure stream via a table 
look-up mechanism containing sixteen look-up tables. Or, it may be a 
subroutine return. Three types of returns are provided: an unconditional 
return or one which returns depending on one of the seventy-two test 
conditions or one which returns to an alternate return location as a 
function of subroutine processing discoveries. 


2.2.15 availability 


The Custom Processor is possessed of data parity checking 
circuits, data uncorrectable memory edac error detectors, and firmware 
parity error detectors. It can also detect references to unavailable 
system resources, and inappropriate return stack references. Parity bits 
accompany data sent from the Custom Processor to other system elements 


allowing them the opportunity of verifying the integrity of the received 
information. 
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J, All Custom Processors include an imbedded comprehensive 
> | self-test firmware routine called the quality logic test (QLT) which, at 


every system initialization, exercises all processor and memory subsystem 
hardware elements verifying their specified’ operation. This firmware 
[ routine includes a thorough memory array test. 


[ 
[ 


major block diagram goes here 
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HARDWARE DESCRIPTION 


This section describes hardware entities at a level of detail 
sufficient for comprehension if the reader has a set of custom processor 
schematics (LBD's) and if the reader has experience in the interpretation 
of logic diagrams. LBD page references are suffixed with m for mother 


board or d for daughter board. Reference is also made to the block diagram 
of 2-5. 


The hardware discussion will be subdivided into fifteen zones. Each of 
these zoses is a separable entity that has one or more firmware fields 
dedicated to its control as shall be seen in section iv. 

The fifteen sections and the block diagram identifier are: 

I. Register file and alu (2991's) 
II. Auxiliary random access memory (ARAM) 
IIt. D bus 
Iv. S bus 
V. Z bus 
VI. Local bus 
VII. Temporary, permanent and control flags 
VIII. Nibble shifter | 
IX. Arithmetic and miscellaneous indicators ~ 
X. OP register and OP register multiplexers 
XI. Load of H, V and other registers ° 
XII. Four-speed clock 
XIII. Return stack 
XIV. Next address generation 
XV. Availability 
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ETE 


In the text which follows, capitalization is used sparingly so that 
all signal names and micro names may stand out. Signal name polarities are 
avoided wherever possible; instead the terms “on” and “off” are used. 
When, for instance, REQNOW is "on", REQNOW+ is high and REQNOW- is low. 
This applies even when the signal exists in only one polarity (e.g., 
“MCX808 is on” means MCX006- is low and would alse mean MCX000+ is high 
were there such a signal. A neutral polarity indicator "." is used for 


those signal names which achieve uniqueness on in their eighth and ninth 
_characters (e.g., NAEB13.EX). 


3-1 Register file and alu (block diagram identifier I) 

‘The ralu is the resource which performs thirty-two-bit arithmetic and 
logic operations. It resides between the dbus, from which it receives 
operands, and the zbus to which it delivers results. 

3.1.1 The 2981's (see page 15d) | 

The ralu is comprised of eight 2901's. These eight chips constitute: 

l. a dual-ported 16-location by 32-bit register file 
2. a 32-d1it arithmetic and logic unit 
3. a 32-bit q register 


4. a shifting element capable of shifting the alu output one bit 
left or right. 


5. a shifting element capable of shifting the concatenation of 
the alu output and the q register one bit left or right. 


6. a zero detector, an overflow detector, a sign detector and 
a carry detector. 


3.1.2 Ralu addressing and control (see lbd pages 34, 4d and 5d) 


The raw control register provides the 2981's almost all of their 


control inputs: 


A port address CRAA(60-983) 
B port address CRAB( 86-83) 
source select | CRAS( 80-82) 
function select CRAF (88-82) 


destination select | CRAD(00-82) _ 


CUSTOM PROCESSOR TECHNICAL DESCRIPTION PAGE 3-2 


| 
| 
| 


3.2.1 Aram read or write (see lbd pages 17d and 19d-26d) 


SECTION THREE 3 HARDWARE DESCRIPTION 


3.1.3 Ralu support logic (see page 12d) 


The carry look-ahead network is comprised of 745182'’s connected in a 
somewhat unconventional manner. First, the carry into the least 


significant 2961 (AUCO32) is derived by decoding bits three and four of 
the AF field to produce four cases: 


AFS AF4 AUC832 
8 8 cause a carry into alu unconditionally 
8 1 cause a carry into the alu if the carry indi- 


cator is off 


1 8 cause a carry into the alu if the carry indi- 
cator is on 


1 1 do not cause a carry into the alu 


Next, the carry into the second 2981 is from the first’s ripple carry. 
Then. the 74S5182's take over, providing input carries for the most 
significant six <991’s. Last, the carry out of the most significant stage 
(AUCO@S) is derived by combining the G and P outputs of the most 
significant 74S182 chip using a couple of inverters and a 74S51. 


The zero detector of the 2981 is an open-collector output requiring 
pullup. Eight resistors are required since the leading-zero indicators 


must examine each individual nibble even though the zero arithmetic 
indicator is partitioned only to the byte. 


The signal ALUTOZ is derived as shown (predecoded) in order to 
enable/disable the 2981's to the zbus in a timely manner (see 5.0). 


3.2 AUXILIARY RANDOM ACCESS MEMORY - ARAM (block diagram indentifier ITI) 


The auxiliary random access memory is comprised of eight 1421-45's. 


Each chip contains 4896 locations of four bit wide static ram. The aram 


receives a twelve-bit address from an eight-way selector called rmad. The 
aram may be read/written to/from the sbus. 


When written, the aram is byte partitioned. When read, 52 bits of data 


are placed upon the sbus for normal reads. The signals RAMWCE, RAMXCE, 
RAMY 


E, and RAMZCE are the four chip enables. They are structured simply 


to provide the split cycle sbus capability having a gate for first half 
cycle,a. gate for second half cycle and a gate to “bridge” the early and 
late gates when the ARAM is the sbus source for the full cycle. The four 
signals ARMOWR, ARMIWR, ARM2WR, and ARMSWR provide the write enable for 
the w byte, the x byte, the y byte, and the z byte, eSen eee ear: 

3.2.2 Aram addressing (see pages 18d and 29d) 


ad 
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The three-bit firmware field RM provides control for an eight-to-one 
selection of aram addressing sources. Twelve 74AS151's perform the 
selection resulting in RMAD(00-11). The table below shows what address 
results from each selection: 


e 


sot RMAD( 86-93) RMAD( 84-97 ) RMADG8-15 ) 
8 zeros GRBR( 60-93 ) OPRGA( 9-3) 
: 1 zeros GRBR(@0-83) . OPRGB(9-3) 
2 . zeros GRBR( 66-93 ) OPRGC( 6-3) 
3 zeros GRBR(68-83) § OPRGD(8-3) 
4 CRFT( 61-04) CRDK( 88-03) CRDK( 64-07) 
5 | P a r & 
6 BSBR( 06-83) BSAR( 69-03 ) BSAR( 94-87) 
7 1,ZBU0S(19-21) ZBUS(22-25) ZBUS( 26-29) 


erbr is a four bit “general bank” register which permits the sixteen 
aram locations accessible by opa, b, c, and d to be any block of sixteen 
in the first 256 aram locations (see 3.11). bsar and bsbr are a four and 
an eight-bit register which together provide an independent aram 
addressing mechanism (see 3.11). ecrft together with erdk provide the 
"literal" address where crdk is part of the dbus control (see 3.3) and 
crft normally controls the temporary flags (see 35.7). The last selection 
has a rather specialized use. It allows 2048 locations of the aram to 
become a cache of control structures where a field of the zbus is used to 
access one of the 2848 locations and data in the accessed location can be 
used 3) determines hit or miss at the discretion of the microcoder (see 
3.9.2.3). 


3.3 THE D BUS (block diagram identifier III) 


- The dbus is a major node in the 32-bit custom processor. It is one of 
three 32-bit buses but it is the most prolific. Data may be deposited upon 
it from a wide variety of sources. Such data may then be made available 
for computation in the ralu, or placed into the output register, or 
transmitted to the zbus. The dbus is structured as four eight-bit buses, 
allowing up to four dbs sources to be combined (see section 4.3 for a 
complete list of tbe combinations and permutations). 


3.3.1 abus byte w - bits 00-087 (see lbd pages 17d, 19d and 204) 


Byte w may receive from six mutually exclusive sources which are 
tg below along with the signal, emanating from a pal, that enables 
each source:. 


were ems. ware: 
~— ame 


= -_ 


source enable signal 
1. the sbus to dbus latch (LTCHS0-07) LTCHWE 

2. the h register (HREGOd-27) HREGWE 

3. the zbus (50SZ093-97) BZTOBD 

4. a fill byte (SGNEXT) 7 FILLWE 

5. the 8 bit "J" literal (CRDJ00-97) CRDIWE 

6. the 8 bit "k" literal (CRDK00-07) CRDKWE 
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There is more discussion of source #1 in 3.4. 


, At the firmware level, the normal fill bit is CRDFOO® which becomes an 
[ input to an eight-to-one multiplexer along with three sbus bits in order 
‘ to provide three 


types of sbus sign extension as a function of certain 
dbus control bits (CRDJ82, CRDJ94, and CRDTRE). The output of the 


multiplexer is replicated 8, 16, 24 or 32 times providing the required 
fill or sign extension. 


a 3.3.2 dbus byte x - bits 88-15 (see lbd pages 17d, 21d and 22d) 


i as Byte x may receive from six mutually exclusive sources which are 
[ listed below along with the signal, emanating from a pal, that enables 
each source: 
7 | source enable signal 
[ 1. the sbus to dbus latch (LTCH@8-15) LTCHXE 
; 2. the h register (HREG@8-15) HREGIE 
[ 3. the hue (4/8260 -19) BZTOBD 
4. a fill byte (SGNEXT)’ FULLXE 
[ 5. petr/p history (PHST08-15) register PCTREN 
6. the 8 bit "k" literal CRDEXE 
| By examination of the last two characters of the enable signal, one 
a. may determine if the source is partitionable or if it is a “broadside” 
—- source. In the six sources above, the latch, the h register, the fill, and 
the k literal are partioned sources whereas the sxbus and the petr/p 
| history are not. 
: 3.3.3 dbus byte y (bits 16-23) see lbd pages 17d, 23d and 24d 


Byte may receive from eleven mutually exclusive sources which are 
] listed below along with the signal, emanating from a pal, that enables 
[ each source: | 
| source enable signal 
| 1. the sbus to dbus latch (LTCH16-23) LTCHYE 
2. the h register (BREG16-23) HREGYE 
[ 3. the zbus (BUSZ16-23) BXToDpD : 
u 4. a fill nibble (SGNEIT) PILLYE.23 
a fill nibble (SGHUEXT) FILLYE. 47 
[ 5. the "3° 3 bait 1it literal (CRDJO8-07) += —_—-CRDJYE — ; 
dd 6. the "k” 4 bit literal (CRDKOe-03) CRDKYE. 85 
the "k" 4 bit literal (CRDK94-07) CRDXKYE.47 
[ 7. the petr/p history register (PHST16-23) PCTREN 
8. the hex decoder (HEXD09-97) : HEXDEN 
‘ 
[ 9. the opa&b registers (OPRGAZ-3 , OPRGBS-3 ) OPRGYS 
| 12. the “procedure® muz (PTODI6-25) PICYEN 
ft. the aram bank registere (GRBRSB-03) | ASBREN 
(BSER9O-23) 
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Sources #4 and #6 are partitioned at the nibble level in order to 
support the micro D:RAMAD-X8 (see 4.3). 


Source #8 is one byte of the hex decoder, a mechanism which decodes, 
with a couple of 74S8138's, the least significant four bits of thé aram 
address (RMADO8S-11) and emits a one in a field of fifteen zeros. 

Source #9 allows the op register to be placed upon the dbus. 


Source #10 for this byte deposits the output of a 2:1 mux onto the 


, dbus. The two sources on the input of the mux are: 


a. the most significant byte of the pbus (BUSP@6-07) 


b. seven fill bits (CRDF93) and the most significant bit 
of opc(OPRGCS) which, with the help of the correspon- 
input on byte z, yields opc/d shifted left one place 
for the micros D:OPCD-X2 and D:OPCD-X2'1. 


Source’ #11 provides access to the independent aram addressing 
mechanism. | 


3.3.4 dbus byte z - bits 24-31 (see lbd pages 17d, 25d and 26d) 


Byte xz may receive from eleven mutually exclusive sources which are 


listed below along with the signal, emanating from a pal, that enables 
each source: . 


source enable signal 

1. the sbus to dbus latch (LICH24-31) LTCHZE 

2. the h register (HREG24-31) | _ HREGZE 

S$. the zbus (BZUS24-31) BZTOBD 

4. a fill byte (SGNEXT) PILLZE 

5. the rmad times 8 mechanism | PCBREN 
6. the 8 bit "k" literal (CRDK90-07) CRDKZE 


“%. the petr/p history register (PHST24-31 ) PCTREN 
8. the hex decoder (HEXD08-15) HEXDEN 
9. the opc&d registers (OPRGCO-3,O0PRGD0-3) OPRGZE 
180. the “procedure” mux (PTOD24-31) | PTOYEN 
11. an aram address register (BSAR@0-07) ASBREN 


Source #5 implements the least significant eight bits of the micro 
D:RAMAD-X8 placing onto this byte the high order k literal bit CRDKOO, 
RMAD( 08-11), and the next three k literal bits (CRDK@1-03). 


Source #10 for this byte deposits the output of a 4:1 mux onto the 
dbus. The four sources on the input of the mux are: 


-~a. the eight least-significant bits of the pbus (BUSPO8-15) 


b. the three least significant bits of ope (OPRGC1-3), 
opd (OPRGDO-3), and the fill bit (CRDF@6). 
This input along with the corresponding input on byte y 
allows the dbus to receive opc/d doubled (CRDF98=98) or 
dibbled (CRDF00=1) for micros D:OPCD-X2 or D:OPCD-x2'1. 
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c. the most significant eight bits of the pbus (BUSP06-07) 


d. registers opc/d shifted right three bits for the micro 
D:OP-BIT-AD ; 


3.4 THE S BUS (block diagram identifier IV) 


The sbus is a very special. kind of 32-bit bus. Although it has a 
limited number of sources and few destinations, it is unique because, in 
two different 32-bit sources. may be placed upon it. The 
“justification for this construction is that data-from the aram must be 
read, modified and written in the same step (the 1421's share input/output 
data pins). Thus the sbus is a split-cycle mechanism capable of having 
data from one source in the early phase of a step (e.g., the aram) and 
another source during the late phase (e.g., the zbus-shifter). Another 
unique property of the sbus is its ability to send either the early data 
or the late data (but not both) to the dbus. This is accomplished via 
transparent latches which, on a byte-partioned basis, either go blind at 
mid-cycle (thus capturing the early sbus data) or remain transparent 
throughout the cycle (thus delivering to the dbus the late sbus data). 
“Byte partioned” means that micros are provided which permit each dbus 
byte independent choice of the early sbus information, the late sbus 
information, or other sources as described in 3.5. 


3.4.1 sbus bytes wv, x, y, and z (see lbd pages 14d, 15d, 21d, 22d, 
17m, 21m, and 33m) 


Bytes xX, J, and gz may receive from eight mutually exclusive sources 
which are listed below along with the signal which enables each source. 
These thirty-two bits of the sbus appear on both the mother and daughter 


boards. Three of the eight sources are on the daughter board and five are 
on the mother board. 


source enable signal 

1. the aram byte w (ARAM@6-62) RAMWCE 

byte x (ARAM@8-15) RAMXCE 

byte y (ARAM16-23) 7 RAMYCE 

byte z (ARAM24-31) RAMZCE 

2. the shifter a output (SHFTO8-51) SFT1EN 

3. the shifter b output (SHFTS8-31) SFT2EN 

4. the stack top (KTOP86-13) and ACTN2S 

the accounting timer (ACIMO5-15) : 

5. the syndrome register (SYND@8-31 ) SYND2S. 
6. address register a (ADRAGS8-31) ADRA2S © 

7. address register b (ADRB@8-31) ADRB2S 

8. address register p (ADRPOS8-31) ADRP2S 


Regarding source #1, the enable circuitry has been discussed in 3.2 
but one should note that when writing the aram, both the chip enable 
(RAMWCE) and the write enable (ARMOWR) must be on. This condition causes 
the 1421 rams’ output circuitry to go to the high impedance state. This 
arrangement allows the sbus to receive data from any other source while 


the aram is writing. 
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Sources #2 and #3 are listed separately because of the configuration 
of shifter chips (25S10's) used. Sixteen chips, each with four output 
pins, are connected in a parallel structure such that, as a function of 
the high order bit of the shift distance (CRSDO0), either one or the other 
group of eight chips is enabled to the sbus (see 3.8). 


Source #4 is, at the full sbus level, a collection of two sources 
which total less than 33 bits. The upper 16 bits “read” the stack top 
(the firmware address which the next RETURN micro will utilize) and the 


. lower 16 bits "read" the accounting timer (see 3.11.8). 


‘Source #5, the syndrome register, is a mechanism which captures 
subsystem configuration information, the most recent error event or reason 


code. The path to the sbus merely allows the coder to view this reason 
code (for more about errors, see 3.159. 


Sources #6, #7, and #8 allow reading adra, adrb, and adrp 
respectively. For more about these registers, see 5.11. 


3.4.2 Sbus enables (see lbd pages 17d, 10m and 17m) 


The sbus control field (CRSS88-82) allows one of six types of sbus 
cycles in any step. The table shown below summarizes the six cases: 


CRSS88-62 early data from late data from 

] adra/b/p adra/b/p 

1 adra/b/p zbus 
2 | synd/actm.stack synd/actm.stack 
3 zbus zbus 

4 8 Pp r e 

3 8 r e 

6 aram aram 

7 aram zbus 


The aram split cycle controls are discussed in 3.2. The general 
technique for the shifter and the address registers is the same; namely, 


there is an input on each enable circuit for the early half of the cycle 
and another for the late half. 


The shifter enable circuits receive an input from a flop (CRSSE3) 
which predecodes the control store word looking for the only code which 
requires the zbus to the sbus during the early phase (1.e., code 3). The 
late input is decoded in a pal. 


The early gate on the address register enable circuits (ADRA2S, 


ADRB2S, and ADRP2S) is timed with MCLOCK whereas the late inputs are 


essentially untimed. Notice that the choice among adra/b/p is the 


responsibility of the BS field and not of the SS field. The 748139 which 
decodes two bits of BS for this purpose is enabled for codes 6, 1, 4, and 


5, but 4 and §5 are not used and @ and 1 are the codes which deposit 
adra/b/p to the sbus. 


3.5 THE Z BUS (block diagram identifier V) 


The zbus is a place where the ralu may deposit its computations, is 


the bus upon which external data arrives (from inra/b) and is the bus 
which feeds the nibble shifter. 
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3.5.1 zbus sources (see lbd pages 16d, 29d, 32d, 33d, and 34d) 


The zbus is thirty-two bits wide and receives from six thirty-two-bit- 
wide sources. Along with the ralu and the input data registers, the zbus 
may receive from the v register, the dbus, and from an external connection 
(i.e., the firmware development facility). The six sources are listed 
below along with their respective enable signals: 3 


source enable signal 
+ 1. dmra (INRAQB-31) .  CRIA2Z 

2. inrb (INRB@O-31 ) CRIB2Z 

3. v register (VRECGd-31) VREGEN 

4. ralu (ALUY@6-31) ALUTOZ 

5- the dbus (BUSD#3-31) DBTPZB 

6. the fdf (BUSZ60-31 .EX) | CRIB2Z 


3.5.2 zbus enables (see lbd pages 12d, and 32d) 


The ZB field controls the zbus sources as shown below: 


crzb( 86-62) source enable signal 

M ralu ALUTOZ 
1 fdf CRTB2Z 
2 inra CRIA2Z 
3 inrb | CRIB2Z 
4 dbus DBTOZB 
) vreg VTRHEN | 
6 inra CRIA2Z 

9 inrb _- CRIB2Z 


All six enables emanate from a pal which decodes crzb. Codes @ through 
5 produce results previously discussed. When inra or inurb is placed upon 
the szbus as a result of code two or three a parity check is performed on 
all four bytes. When inra or inrb is placed upon the zbus as a result of 


code six or seven, a parity check is performed on only the two most 
Significant bytes. 


3.6 THE LOCAL BUS (see block diagram identifier VI) 
The local-bus hardware can be divided into four sections: 
An addressing mechanism 
A data storage mechanism 
A procedure storage mechanism and 


Local-bus control circuitry 


The BS field is responsible for managing the resources represented by 
the above list which contains three address registers, 64 bits of 
procedure stream storage, and 64 bits of data storage. 
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3.6.1 Local bus addressing (see lbd pages 18m, 19m, and 208m) 


Addresses from the processor to the memory subsystem(s) may emanate 
from one of three sources: adra, adrb, or adrp. A three-to-one mux is 
formed using 74S241'’s selected by ADRAEN, ADRBEN, and ADRPEN. Once the 
selection has been made, the address is latched via another group of 
74S241's connected as a batlatch. (A batlatch is used to eliminate 
propagation delay. Batlatches require delicate timing.) Thirty nanoseconds 
into a firmware step which has made a local bus request, the flop ABATEN 
comes on, enabling the batlatch which connects its input to its output. 


““About thirty nanoseconds later, ADRS@PF comes on, disabling the 


multiplexer. The batlatch thereby swallows its tail. 
3.6.2 Local bus data storage (see lbd pages 32d, 33d, 34d and 34m) 


Data from the local bus is captured off the local bus with a 
transparent latch (1.e., four 74S373's). The behavior of the signal LBLOOK 
is that it puts the latch in transparent mode sometime after the request 
to memory has been made; as soon as the memory signals that valid data is 
present on the interface (DCNNUS), the latch is closed. The data may now 
be safely transferred to either inra, or inrb dependent upon which was 
requested. . 


The signals _DALOOK and DBLOOK perform the transfer of data from the 
local-bus latch to inra or inrb. During the step in which the request was 
initiated, both these ‘looks’ clear. At the beginning of the step 
immediately following the request, the appropriate look activates causing 
the latched data to flood into inra or inrb. The look signal remains on 
until the next local-bus request occurs. 


3.6.3 Local-bus procedure storage (see lbd pages 15m, 16m, 28m, 30m, 34m 


The mother board captures local-bus data in the same manner as the 
daughter board, using a duplicate set of 74S375 transparent latches. From 
the local bus latch, the information moves into the procedure "prefetch" 
buffer. This buffer receives procedure 32 bits at a time and dispenses 
procedure either eight or sixteen bits at a time. In order to allow for 
eno look-ahead, the procedure buffer can remember eight bytes (64 
bits). Thus the destination for each 32-bit delivery from the local-bus’ 
latch alternates; the first 32 bits are placed in the procedure buffer at 
bytes a, b, c, and d; the second 52 bits are placed in the procedure 
buffer at bytes e, f, g and h; the third 52 bits are placed in a, b, c, 
and d again etc..The alternation results from the look signals (PALOOK and 
PELOOK) taking turns, because pareqt and pereqt take turns because FRELOD 
complements each time a procedure request is made. 


In order to dispense one byte at a time, eight 748375 chips form this 
64-bit storage register with their outputs connected together to form an 
eight bit bus. The output of this network is called BUSPO0-07. A three bit 
counter, called the take counter, keeps track of_which byte is next for 
delivery onto BUSP90-07. When PTAKE4/2/1=6, the first latch chip 


*(INRPAG-7) is enabled onto BUSP@8-07, when PTAKE4/2/1=z1 then INRPBO-7 is 


enabled onto BUSP@98-07 ... and when PTAKE4/2/1=7, then INRPHO-7 is enabled 
onto BUSP99-87. | 


In order to dispense two bytes of procedure at a time, eight more 
748373's form a completely duplicate 64 bit storage register also with 
their outputs connected together to form an eight-bit bus, but this bus is 
called BUSP@8-15 and the network differs from the one previously described 
only in enabling. Above, when PTAKE4/2/1=1, BUSP90-07 received from 
INRPBG-7; in that instance, the secondary buffer enables INRPC8-7 to 
BUSP@8-15. Thus whatever byte the take counter sends to BUSPO9-87 from the 
primary procedure buffer, the next byte in line is sent to BUSPO8-15 from 
the secondary buffer. 
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Decoding the take counter is accomplished with a 745158. The take 
counter itself is comprised of three 74S112 j/k flops which, with the help 


of a pal, increment by zero, one, or two each firmware step, recording the 
removal of procedure bytes. — ° 


3.6.4 Local-bus control circuitry (see lbd pages 9m, 11m, 28m and 33m) 
Sometime during the middle of each firmware step, the address of the 


next firmware step is determined by mechanisms described in 3.14. Sometime 
near the end of each firmware step, the output. of the control-store array 


‘““(the next firmware word) becomes valid. The BS field emanates from the 


control-store array at bits 128-127 (CSBSC8-7) and is captured in eight 
control register flops (CRBUS8-7). Processor timing is such that CSBSCO0-7 
are valid 2@8ns before the end of each step allowing certain decisions to 


be made before the next step actually begins. Two decisions are made which 
are related: 


1. Does the action in the upcoming step require that a request 

' to a memory subsystem be intiated? 

2. Does the action in the upcoming step require that the 
present step be delayed in terminating? 


If, for any reason, a transaction between the processor and a memory 
subsystem is in .process, the signal REQNOW is on. As an illustration of 
the two decisions above, suppose a firmware sequence is encountered which 
calls for two memory writes in two consecutive firmware steps. As the 
first step nears completion, CSBSCO-7 alerts the request logic (REQTEN, 
REQUST, and the flop USREQT) that the next step will initiate (another) 
transaction but, since only one transaction may proceed at a time and 
since the first memory write is still in process, this step must be 
delayed in terminating (stalled). Thus, REQNOW and CSBSCO-5 have a 
significant impact upon the clock logio (see 35.12). USREQT gets a chance 
at the beginning of every step and is, of course, structured to assume 
that whatever stall was required, has occurred and has been released. 


A summary of the control sequence {is as follows: 


1. USREQT comes on at the beginning of any step which ini- 
tiates a memory-subsystem transaction. 


2. An array of PALs determines whether the request is to be 
sent to Memory Subsystem #1 (or Memory Subsystem #0) 


a. MIREQT is clocked by USREQT and activates if the 
tri-state request collector MIRQTID.@0 is true 


b. MIRQTD.601-95 are active in 32-bit address systems 
(ADDR3221) if MiIPRZT (M1 present) is true 


c. MIRQTD.-04,05 are active in 24-bit address systems 
(ADDR32=8) if MIPRZT (M1 present) is true 


d. MIRQTD.94 is active to disengage the network if Mi is 
not present 


e. M@REQT is also clocked by USREQT and activates for all 
cases where MiREQT does not: ; 


Memory Subsystem #1 not present 
A lock/unlock memory reference 
A memory reference not in M1 space 


A non-memory reference 
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2. immediately, REQNOW comes on. 


3. the memory subsystem “grants” the processor. (If the me— 
mory subsystem was not busy, the grant arrives in about ° 
58ns; but if it was busy, who knows.) 


4. about 5@0ns after the grant is received, USREQT goes off. 


5. now REQNOW is in charge and will remain on until the trans- 
‘ action completes: 


a. for memory reads, when data arrives from memory 
(DCNNUS signals the arrival and OUTREN is off) 


b. for i/o reads, when the data arrives from the MEGABUS — 
(second-half bus cycle) via the memory subsystem 
(DCNNUS signals the arrival and OUTREN is off) 


c. for i/o reads where no data arrives, when grant 
(RQGTUS) goes off. 


d. for all writes, when grant goes off. | 
Once the request is initiated, the firmware sequence is permitted to 
go on its merry way, ignoring the local-bus interface until such time as a 


resynchronization point is encountered (e.g., a data stall, a new local 


bus transaction initiation). During this interval, the transaction is 
remembered in three storage elements: 


1. the thirty-two-bit address is in the batlatch of 3.6.1 
2. the data to be written (if any) is in outr 
3. the control information is in the "fred" register 
Item #3 above is comprised of two registered pals. One pal monitors 
eight inputs and creates six local-bus control signals. Notice that the 
pal is allowed to change its output values only on the leading edge of 


each new memory subsystem request, snapshotting its other seven inputs to 
decide whether this transaction is: 


- 1. a write? (FWRITE) 
2. a doubleword read/write? (FRDBLW) 
3. a lock/unlock? (FRLOCKX) 
4..a memory reference? (FRMREF, two copies) : 
5. to use adra, adrb or abrp? (FRBUS2/35)_ . | 
~-6.-to capture the ACK/NAK indicator (ACKREN) 


A second pal (16R6B) monitors four inputs and generates three outputs 
deciding whether this transaction is: 


1. to send a response notification? (LBSHBC) 


2. to write only eight bits of the first sixteen (LBWCT!) 
Note: other system elements refer to this signal as xxBYTE 


3. to write all sixteen bits of the second sixteen (LBWCT2) 
Note: other system elements refer to this signal as xxDBPL 
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A third pal (16R6b) monitors ten inputs and creates four local-bus 
related outputs which determine whether this step is: \ 


1. one which initiates a local bus request (CRREQT) 


2. one which performs a local bus “wrap” test (CRWRAP) 
3. one which will consume (one or two bytes of) procedure 


; we 4. one which will change the procedure steerage mechanism 

< (FRELOD). If FRELOD=0, arriving prefetched procedure is 
captured by procedure buffers A, B, C, and D. If FRELOD=1, 
arriving prefetched procedure is captured by procedure 
buffers E, F, G, and H. 


3.7 TEMPORARY, PERMANENT AND CONTROL FLAGS (block diagram identifier VII) 


There are twenty-four flags organized as three groups of eight. 


Sixteen of the twenty-four are controlled by one firmware field while the 
other eight have their own. 


3.7.1 temporary flags (see lbd pages 9m, 24m and 29m) 


The temporary flags are controlled by the FT field (CRFTOGO-64). 
Seventeen of the thirty-two possible codes are devoted to the temporary 
flags; one to clear them all, eight to set one of them at a time and eight 
to clear one of them at a time. The flops themselves are a 7418259. One 
pal output (CLRIFL) determines when a broadside clear occurs, and another 
(FLGTEN) determines when a one-bit change occurs. The polarity of the 
change is determined by the data input CRFI99. Which flop is to change is 
determined by the select inputs CRFTO2-84. The eight outputs are 
synchronized by a 74S374 and sent to eight test-condition inputs (see 
3.14). FLGI6E, temporary fl 6 before synchronization, is the data bit 
written into the stop code ram (see 3.9.2.1). 

3.7.2 permanent flags (see lbd pages 13m, 28m and 29m) 


The permanent flags are controlled by the BS field (CRBUSO-7). 
Sixteen of the possible 256 codes are devoted to the permanent flags; 
eight to set one of them at a time, and eight to clear one of them ata 
time. The flops themselves are a 74S259. A broadside clear occurs at 
master clear. A pal output (FLGPEN) determines when a one bit change 
occurs. The polarity of the change is determined by CRBUS3. Which flop is 
to change is determined by the select inputs CRBUS5S-7. The eight outputs 
are synchronized by a 74S374 and sent to eight test conditions ace 3.14). 
Permanent flag #7 (FLAGP7) is one of the "break" stimuli. 


Pat are control flags (see lbd pages 24m, 27m, 29m and 33m) 


The control flags are controlled by the BS field (CRBUSO-7). Sixteen 
of the possible 256 codes are devote to the control flags; eight to set 
one of them at a time, and eight to clear one of them at a time. The flops 
themselves are a 74LS259. A broadside clear occurs at master clear. A pal 
output (FLGCEN) determines when a one-bit change occurs. The polarity of 
the change is determined by CRBUS3. Which flop is to change is determined 
by the select inputs CRBUS5-7. The eight outputs are sychronized by a 
748374 and sent to eight test conditions (see 5.14). Some of the control 
flops have side-effects: 


[ 
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FLAGCO off line 
FLAGC! qlit failed (if flagc® is off) ; 
FLAGC2 generate even parity to outr (if flagce® is off) 
FLAGCS enable the accounting timer 
2 FLAGC4 undedicated 
— FLAGCS inhibit disaster 
FLAGC6 undedicated 
FLAGC7 stack error detection enable 


3.8 NIBBLE SHIFTER (see block diagram identifier VIII) 


The nibble shifter is the only connection between the zbus and the 
sbus and is therefore in a critical path. The shifter is really an eight 
nibble rotator; there is no distinction for instance between, shifting 
three nibbles left and shifting five nibbles right. 

3.8.1 shifter data flow (see lbd pages 11d, 14d and 15d) 


The shifter is implemented with sixteen 25518's connected as two 
parallel groups of eight. The first group is enabled when the shift 
distance prescribed by the SD field (CRSDO0-02) is either zero, one, two 
or three, and the second group is enabled when the shift distance is 
either four, five, six, or seven. 


The 25S18 whose output names are SHFTOO.SA, SHFTO4.SA, SHFTO8.SA and 
SHFT12.SA reveals first that this chip is enabled for shift distances of 
9, 1, 2, or 3 and that for a distance of zero, the chip internally 
comnects its four outputs to its lowest four inputs; for a shift distance . 
of one, the four outputs are connected to the next higher four inputs; for 
a shift distance of two, to the next higher four inputs; and for a shift 
distance of three, to the top four data inputs. 


The second group of eight shifter chips operates like the first, but. 
are enabled for shift distances of four or more and thus their data inputs 
are wired bias by sixteen bit positions. 


3.8.2 Shifter control (see lbd pages 10m, 11d, 14d, 15d and 17d) 


Since the shifter deposits its result onto a split-cycle bus, the 
enable requires early/late timing. For SS (CRSS00-2) code three only, the 
shifter is enabled to the sbus during the early phase; a pal generating 
signals SiLATE and S2LATS determines what circumstances allow the shifter 
to the sbus during the late phase. 


3.9 ARITHMETIC AND MISCELLANEOUS INDICATORS (block diagram identifier IX) 


There are six arithmetic indicators and eight miscellaneous 
indicators. The intent of these indicators is to allow the coder to 
remember some characteristic(s) of some data for the purpose of affecting 
the addressing sequence of a subsequent firmware routine. 


3.9.1 arithmetic indicators (see lbd pages 5d, 12d, 13d, 27d and 28d) 


a_Z FREE eee Oe ae Se eSelUmPeelUPCUe 


Five of the six arithmetic indicators derive their inputs from the 
output of the alu. The sixth samples the least-significant bit of the zbus 
(BUSZ31). In addition to storage for the indicators, four 4:1 muxes are 
employed. Three of the muxes are halves of 74S153’s and one is a 74S64. 
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‘The overflow mux (OVFMUX) selects one of four 2981 overflow signals as 
a function of the ID code (CRID@6,01) as follows: 


CRIDG6,61 overflow source 


88 carry into alu bit 24 not ae to carry 
out of alu bit 24 


oe e1 | carry into alu bit 16 not equal to carry 


out of alu bit 16 


16 carry into alu bit @8 not equal to carry 
out of alu bit 0&8 


11 carry into alu bit 08 not equal to carry 
out of alu bit 88 


The carry mux (CRYMUX) samples one of four alu carries as a funciion 
of the ID field as follows: 


CRIDOO, 01 carry source 
oe carry out of alu bit 24 
ot | carry out of alu bit 16 
18 carry out of alu bit 98 
141 carry out of alu bit 08 


The sign mux (SGNMUX) samples one of four alu "signs" as a function of 
the ID field as follows: 


CRIDOG,01 sign source 
80a alu output bit 24 
81 alu output bit 16 
18 alu output bit 88 
. 41 alu output bit 69 


The zero mux (SZRMUX) samples four groupings of bits as a function of 
the ID field as follows: 


CRID2S, 01 zero source 
80 if alu output bits 24-31 are all zeros 
01 if alu output bits 16-31 are all zeros 
16 | if alu output bits 68-31 are all zeros 
11 if alu output bits 88-31 are all zeros. 


These four mux outputs are stored into the overflow indicator 
(OVFIND), the carry indicator (CRYIND), the sign indicator (SGNIND), and 
the zero indicator (SZRIND) at the behest of a pal output (AINDEN). Also 
captured are the double sero indicator (DZRIND) and the odd indicator 
(ODDIND). A code emanating from the FT field causes the arithmetic 


indicators to "clear" such that four indicators are off and the zero and 
double-zero indicators are on. 
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3.9.2 miscellaneous indicators (see lbd page 27d) 


The eight miscellaneous indicators can be divided into one group of 
four and four groups of one. A pal output (BINDEN) determines when the 
miscellaneous indicators sample their inputs. 
3.9.2.1 SCRAM indicator 


The stop code ram is a 256-location by one-bit-wide memory addressed 
from byte y of the dbus. It is written from FLGT6E under command of a pal 
output (WRSCRM) modulated with appropriate timing. Its data output is 


“‘eaptured along with the other seven miscellaneous indicators when the pal 


output BINDEN occurs. : 
3.9.2.2 DIFBUF indicator 


This mechanism compares eight bits of the dbus with eight bits of the 
zbus utilizing a 74F521. 


3.9.2.3 HASHIT indicator 


This mechanism compares thirteen bits of the zbus with thirteen bits 
of the sbus utilizing two 25LS2521's. 


3.9.2.4 ILLADD indicator 


This mechanism uses a 16L8A pal to decide whether the rightmost byte 
of an operand is in the same 512-byte buffer as a specified base address. 
The pal assumes that the base address and the displacement locating the 
leftmost byte of an operand are being added in the alu, that one of these 
values is on the dbus, and that the type register contains the operand- 
length information (1, 2, 4 or 6 byte operand). The pal would prefer a 
carry signal out of alu bit 235 but one is not available so the pal derives 
it from the input carry to alu bit 23 (AUCO24), the dbus bit 23 (BUSD23) 
and the sum bit 23 (BUSZ23). 


3.9.2.5 leading zero detector 


This mechanism, utilizing a 16L8A pal, determines the number of 
leading zeros present in the value from the alu. The pal receives the zero 
detector from each of the eight 2981's. The outputs from the pal (AUPZé8, 
AUPZ84, AUPZ@2, and AUPZ81) are captured in the miscellaneous indicators. 
The four indicators (PZ8IND, PZ4IND, PZ2IND, and PZ1IND) are coded such 
that: 9860080 means no leading-zero nibbles were detected, 9181 means that 
five leading-zero nibbles were detected and 1008 means the entire alu 
output was zero. 


3.10 THE OP REGISTER (block diagram identifier Xx) 


Certain bytes and/or nibbles of the procedure stream must be stored 
for future reference. The four 4-bit wide registers opa, opb, opc and opd 
provide -- said--storage.__ These four registers can also be loaded from the 
sbus, can be incremented or decremented, and have the ability to address 
the aram. The seven bit field OP controls the entire op area. 


3.19.1 the sbus multiplexer (see lbd pages 10d and 31d) 
When the op register(s) are to be loaded from the sbus, the sbus 
multiplexer (SMUX90-15) is required to narrow the 32-bit sbus to a width 


of 16 bits, matching the width of the op muxtiplexer. CROPO2 decides 
which half of the sbus is chosen. 
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3.18.2 the op multiplexer (see lbd pages 18d and 31d) 


The op multiplexer (OPMX88-15) ie comprised of four 16L8A pals. Each 
pal has four data outputs, nine data a=i four control inputs. At the first 
level, the choice is between the fous data inputs and the sbug data 
inputs. At the next level, a choice of which nibble of the selected bus is 
to be directed to the output (sort of a rotate). And at the last level, a 
choice as to whether the four bit literal inputs (CRFT@1-04) should be 
presented to the outputs. All this is cex=trolled by the inputs CROPOO-93. 


_ 3.10.3 The op registers (see lbd page 312) 


There is a 74AS169 for each of spa (OPRGAS-3), opb (OPRGBG-3), ope 
(OPRGCO-3), and opd (OPRGDO-3). Loadi=g, incrementing or decrementing is 
controlled by a pal which emits, for each register, one load signal and 
one count signal. For opa, the load sizsaal is OPALOD and the count signal 
is OPAPAT . When the count signal is on, the appropriate op register 
increments if crop@2 igs on and decrements otherwise. OPATOP, OPBTOP, 
OPCTOP, and OPDTOP are provided to detect when the counter in question is 
"wrapping" (in the firmware verna- cular) i.e., incrementing from F to 
zero or decrementing from zero to F. 


3.18.4 the type register (see lbd page 3‘ da) 


The type register stores two bits in a 745169. The input to the type 
register is the same as the two most sisnificant inputs of opa. The unused 
two stages of the 74S169 are wired so that when the type is 11 (three), 
the "carry" output of the chip (TYPISZ) will be on. A signal from the FT 
field (CLRIFL) clears the type register and a load signal (TYPELD), also 
from an FT pal, performs the load honors. 


3.11 LOADING VARIOUS REGISTERS (block diagram identifier XI) 


Many firmware fields have no other purpose but to control the loading 
of various registers. These fields are H, LA, LO, and LV. Other fields 
have a secondary justification for existence by providing the load 
controls to certain registers in need. Trese fields are BS and FT. 


3.11.1 loading the H register (see lbd pages 18d, 17d, 208d, 22d, 22d, 26d) 


The H register is loaded at the behest of a dedicated control store 
bit (CSHO56 ) with its attendant control-register flop (CRHOO8) 
pulse-formed in HREGLD. 


3.11.2 loading the output register (see lbd pages 11d and 35d) 


The output register (OUTRO6-31) is loaded at the behest of a dedicated 
control store bit (CSLOAS) with its attendant control-register flop 
(CRLOG88) pulse-formed in outrck. Note that 36 bits are captured with this 
load stimulus; namely, the 32 bits of the dbus and four byte-parity bits 
in flops OUTROP, OUTRIP, OUTR2P, and OUTRS5P. These four parity bits are 
generated by four 82s62 parity. generator/checker—-chips- called MYDP86, 
MYDP88, MYDP16, and MYDP24. See section 3.15 for more about checking. 


3.11.3 loading the v register (see lbd pages iid and 34d) 


The v register (VREG@0-31) is loaded at the behest of a dedicated 
control-store bit (CSLV96) with its attendant control register. flop 
(CRLV68) pulse-formed in vregld. 
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3-11.4 changing adra, adrb, and adrp/pctr (see lbd pages 10m, 26m 
3 17d, 21d, 23d and 26d) 


Four control-store bits (CSLAB6-9) and four cr flops (CRLAGO-03) are 
provided to control the changing of the three address registers. Each 
address register is thirty-two bits long and is comprised of four 74AS869 
chips. Address registers adra (ADRAO9-31) and adrb (ADRBOG-31) may be 
loaded from the shus, or may be incremented by four, or may be decremented 
by four. The address register adrp (ADRP@0-31) may be fully loaded from 


_ the . sbus or may have only its nine least significant bits copied from the 


“sbus or may have its twenty-three-most-significant bits copied from the 
sbus. Note that adrp is implicitly incremented by four whenever four 
procedure bytes are requested from the memory subsysten. 


The pal which controls all this generates two mode bits (ADRAM@,1) and 
a carry-in (ADRACI) for adra, and two mode bits (ADRBMO,1) and a carry-in 
(ADRBCI ) for adrb. When ADRA/BM9=8 and ADRA/BMis1, the register 


decrements; when md=1 and mis0, the register increments; and when m@=1 and 
mizi, the register loads from the sbus. 


For adrp, the pal generates two load signals (PULOAD, PLLOAD) for 
copying twenty-three or nine sbus bits into adrp. Because of the partioned 


load and the necessity to increment by four, a thirty-third flop is 
required to storé ADRP39. 


The register PCTR(08-30) mimics adrp for loading actions. Its bit 
justification in the three 74AS869 chips permit incrementing by one or two 
when procedure bytes are removed from the prefetch buffer. When petr is 
delivered to the dbus, the least-significant bit of the take counter 
(PTAKE!) becomes the units position of pctr. 


3.11.5 changing arbr (see lbd page 36d) 


The four-bit register GRBR(80-03) is used in combination with opa,b,c, 
and d to address the aram. The OP field controls grbr. A 16R8A pal 
receives the seven control-store bits of the OP field and generates 
control signals for the 74AS169 chip which houses grbr. The pal output 
GRBRLD causes GRBR(88-83) to load from the four most significant bits of. 
the opmux (OPMX99-03). The pal output GRBRPT causes GRBR(@8-083) to 
increment by one or decrement by one as a function of CROP@2. If CROPG2 is 


on, arbr increments; if CROP@2 is off, grbr decrements. The firmware name 
for grbr is rbr. 


3.11.6 changing bsbr (see lbd page 30d) 
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The four-bit register BSBR(@08-03) is used in combination with 
BSAR(@8-87) to address the aram. The OP field controls bsbr. A 16R8A pal 
receives the seven control-store bits of the OP field and generates 
control signals for the 74AS169 chip which houses bsbr. The pal output 
BSBRLD causes BSBR(88-83) to load from opmux bits 4-7 (OPMX04-07). The pal 
output BSBRPT causes BSBR(80-83) to increment by one or decrement by one 
as a function of CROP@2. If CROPS2 is on, bsbr increments; if CROPG2 is 
off, bsbr decrements. The firmware name for bsbr is rarh. 


3.11.7 changing bsar (see lbd page 36d) 


The eight-bit register BSAR(08-97) is used in combination with bsbr to 
address the aram. The OP field controls bsar. A 16R8A pal receives the 
seven control-store bits of the OP field and generates control signals for 
the two 74AS169 chips which house bsar. The pal output BSARLD causes 
BSAR(@8-07) to load from the eight-least significant bits of the opmux 
(OPMX0815). The pal output BSARPT causes BSAR( 20-07) to increment by one 
or decrement by one as ae function of CROP@2. If CROP@2 is on, bsar 


increments; if CROP@2 is off, bsar decrements. The firmware name for bsar 
is rarl. 


3.11.8 loading the accounting timer (see lbd pages 24m and 33m) 


The accounting timer is a mechanism which provides real time 
information for job accounting and other purposes. The accounting timer is 
constructed from two 74AS869 counter chips wired to either load or 
increment. The timer (ACTM@6-15) has a 100 microsecond period (i.e., it is 
incremented at a i8khz rate when enabled by FLAGC3). It is loaded by an 
FT-field micro decoded by a 16L8A pal (ACTMLD) which invokes an implicit 
clock stall (see35.13) whose purpose is to insure that an accounting timer 
clock (MHZ801) occurs while the data to be loaded from the sbus is valid 
at the inputs of the 74AS869 chips. Note that when the accounting timer 
increments from 65,535, an accounting timer interrupt (ACTINT) is stored. 
This interrupt (synchronized through ACTITF) asserts the break stimulus 


and thereby causes a “derail” at the next sample of break by the RNI 
macroe . 


3.12 THE FOUR SPEED CLOCK (block diagram identifier XII) 


The custom processor resides in an asynchronous world. The custom 


processor clock is an asynchonous mechanism. The clock has two orthogonal 
properties: 


1. the clock allows the duration of each firmware step to be any one 


of four lengths as a function of the combination of micros coded in 
that step. ; | 


2. the clock allows each firmware step to delay its completion until 
some external event occurs. 
3.12.1 the basic clock (see lbd pages 3m and 4m) 


The basic clock has three delay lines, three delay-line drivers, one 
one 74864 and two switch banks for adjustment purposes. Two of the three 
delay lines are connected in parallel. When MCX000 occurs because all of 
its inputs are high (take it on faith), a positive to negative edge 
travels down the 100ns delay line MCX818 through MCX1800. At about the sane 
time, MCX919 creates an edge of the opposite polarity (negative to 
positive) traveling down the delay line MCPW05 through MCPW58. The outputs 
of this latter delay line are switch selected to create the width of 
MCLOCK. This is accomplished by connecting the output of the switch bank 
(MCKPWA) through a 74S64 (MCSTLA) to the original delay line driver 
(MCX900) making one of its inputs low which achieves a pulse width of 
about 7@ns. Having established that a "negative" seventy-nanosecond pulse 
is wending its way down the MCX016-100 delay line, it is now appropriate 
to pursue what happens to cause the cycle to complete (and start over). In 
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the simplest case (i.e., the fastest clock speed), MCX8900 causes the delay 
line driver MCY888 to go high. The delay line MCY#10-030 is now 
propagating a “positive® seventy-nanosecond pulse. The output of the 
switch bank to which this delay line is connected (THEEND) has the 
responsibility for terminating the cycle. That is accomplished by first 
sustaining the effect which MCKPWA achieved upon MCSTLA. When MCKPWA rose, 
MCX888 went high and MCLOCK went low signifying the “middle” of the cycle 
and completing MCKPWA’s contribution. Just before this midpoint, THEEND is 
allowed to take over the responsibility of keeping MCLOCK low. The stage 
is now set so that when THEEND gets exhausted, the cycle ends and, of 


3.12.2 the gear shifter (see lbd page 4) 


The clock speed for each firmware step is selected when the firmware 
is assembled. The assembler or an agent thereof selects, as a function of 
the particular combination of micros in every step, a two-bit clock speed 


code for the CK field. Listed below are the four speeds and their 
definition: 


cx - definition | 

890 very fast (vf) 
31 : half fast (hf) 
18 half long (hl) 
11 | very long (vl). 


Control-store bits 64 and 65 (csck64, 65) are sampled by a 16R6A 
registered pal which generates three clock-speed-enable signals. On the 
delay line driver MCY@09, one “diode” is devoted to each of four delay- 
line taps as selected by the clock enable outputs of the pal. For a very 
fast speed, no enables from the pal are active and the operation is as 
described above (fi.e., the vf tap is always enabled). For a half-fast 
step, CKHFEN from the pal causes MCLKHF to sample another delay-line tap 
which has the effect of extending the on time of MCY8900; that is, it goes 
positive at the same time as a vf step but lasts longer and makes THEEND: 
last longer. It was established previously that the positive to negative 
transition of THEEND ends the firmware step, so now, because of CKHFEN, 
the MCLOCK low time increases. 


When a half-long step is prescribed, both CKHFEN and CKHLEN activate 
causing three of the four inputs of the delay line driver MCY998 to get 
into the act. The additional contributor, MCLKHL, stretches the high time 
of THEEND even further and increases the delay to the completion of the 
step. eS 


Finally, when a very-long step is required, all_ inputs to MCY006 get a — -- 


turn because all three enable outputs of the pal (CKHFEN, CKHLEN and 
CKVLEN) are active, and the high time of THEEND stretches even further 
creating the longest firmware step available. 


The 16R6A pal from which the clock speed enable signals emanate 
provides another service. It monitors six control store bits involved in 
return stack functions (see 3.13) and detects certain firmware sequences 
which require a non-minimum clock speed setting. 


3.12.3 clock stalls (see lbd page 3m) 
Four 74864's provide the inputs for. stalling the clock from “external" 


stimuli. The basic clock operation uses two of the sixteen inputs; that 
is, the MCKPWA oontrols the clock first-phase pulse width and the THEEND 
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input controls the second-phase pulse width. The other active input gates 
provide stalls for the conditions listed below. Each gate must be off 
during the first phase of the step. During the second phase of the step, 
these gates are ignored until THEEND relaxes (the gear shifter time has 
elapsed). Then these gates come into play each having the power to 
postpone the completion of this step. 


stall gate explanation 
CSBSC8.CSBSC2.REQNOW stall WHEN the next firmware step is to 
as unconditionally initiate a local-bus 


request IF previously initiated local- 
bus activity is still in progress. 


STLADU.REQNOW stall WHEN an explicitly coded stall 
micro requires that the completion of | 
this step be postponed until inra re- 
ceives local-bus data from a previous 
request IF the data has not yet arrived. 

CSBSCO.BLOTHR.REQNOW Stall WHEN the next firmware step is to 
conditionally initiate a local-bus re- 
quest and the condition is satisfied IF 
previously initiated local-bus activity 
is still in progress. 


DSTFF1 .WAITUP stall WHEN a hardware error has been 
detected until such time as the reason 
code (syndrome) has been captured in 
HWIA(@8-13) and the next-address gene- 
rator has generated and accessed loca- 
tion zero. 


BSYSTL.REQNOW stall WHEN an explicitly coded stall 
micro requires that the completion of 
this step be postponed until all local- 
bus activity has subsided IF local-bus 
activity is still in progress. 


TBSTOP stall if the firmware development faci- 
iity says so. 
CSBSC1.CSBSC4.EMPTEE stall WHEN the next firmware step will 


examine byte(s) of the procedure buffer 
IF the procedure buffer is empty. 


POWRON .MYMCLR stall during the master clear pulse 
stimulated by power coming on. 


PLLOAD.REQNOW stall WHEN an explicitly coded load of 
adrp-lower occurs IF previously initia- 
ted local-bus activity is still in pro- 

rs -. 711. Sa er ree near 


LOADED stall WHEN an explicit load of the 
| accounting timer is required UNTIL the 
accounting timer clock (mhz001) has had 


an opportunity to sample the sbus 
inputs. 


CSBSC8.CSBSC5.REQNOW stall WHEN the next firmware step will 
initiate a prefetch IF previously ini- 
tiated local-bus acivity is still in 
progress. 


_ STLDBU.REQNOW stall WHEN an explicitly coded micro re- 
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quires that the completion of this step 
be postponed until the data previously 
requested for fnrb arrives IF the ¢ata 
has not yet arrived. 
PAUSED.ACT2S — stall WHEN an explicit read of the ac- 
counting timer is in process IF the ac- 
counting timer is about to incre=ent. 


3.135 THE RETURN STACK (block diagram identifier XIII) 


as The return stack is a last-in-first-out (1ifo) mechanisa for storing 


and retrieving firmware addresses. It can store seventeen addresses. A 
firmware address is written into the stack when any of the three pusn 
micros is executed. An address is read from the stack when ary of the 
return micros is successfully executed. An unconditional returns is always 
successful; i.e., it uses and discards the stack’s ‘°top* entry. A 
conditional return is successful only if the test condition is met; if the 
condition is not met, the stack is undisturbed. A push is performed in 
preparation for calling a subroutine and a return is the mechanis=a used to 
exit a subroutine. The return stack hardware is comprised of: 


1. a 16-location return stack 

2. a 4-bit return-stack address register 

3. a return-stack local register 

4. a "relative push” local register 

5. an "absolute push” local register 

6. a hardware-interrupt address register 

7. a return address bus 

8. an overflow/underflow error detector 
3.15.1 the 16 location return stack (see lbd page 25m) 

The sixteen-location return stack is comprised of four 745189 chips 
providing a 16-by-16 array. Since the firmware address space is 16k, only 
fourteen data bits are used. The data out (RIRN@8-15) is connected to the 
return-memory local register (KRAMO0-13). The memory is addressed by a 
four bit address register (FWSTK9-3). 7 
3.13.2 the 4-bit return-stack address register (see lbd page 24m) 

The return-stack address register consists of one 748169 counter chip. 
The counter may be initialized to a known state via FSTKLD, which is used 
in testing and other situations. In normal operation, a push causes the 
counter to increment before a new entry is written into the stack, and a 
pop (RETURN) causes the address register to be decremented after the entry 
has been read from the stack. First, notice that the counter chip "clocks" 
at midcycle(MCX068); then, notice that the counter chip increments if 
CDPUSH afrom a pal); and last, that it counts if PSNPOP (also from a pal). 
The 16L8A from which these signals emanate has inputs which permit it to: 

1. CDPUSH: in any step in which a push micro is coded unless the pre- 

vious step performed a successful return. 

2. POPING: in any step which performs a successful return. 


3. PSNPOP: 1 or 2 above. 
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3.13.3 the return-stack local register (see lbd pages 24m, 25m) 


In a successful return, the return address bus is sent to the next- 
address generation circuits. The next return candidate is then read from 
the return stack into the return-stack local register so as to be 
available for the a subsequent return. A_ successful return generates 
POPING which is pulse shaped into POPCLK for capturing, in KRAM(@6-13), 
the data output of the ram chips. The output of the return-stack local 
register, like the other three registers which capture return addresses, 


, 1s connected to the return address bus (FSTK00-13). 


3.13.4 the relative-push local register (see lbd page 25m) 


One of the push micros allows the address saved to be relative to that 
specified in the next-address field (CRNAG1-15). A relative push creates a 
firmware address to push by combining the eight most significant bits of 
crna with the five bits of the ft field and always pushing an if bank 
address. This combination of fourteen bits is captured in the relative 
push local register (NAFI@0-13). Capturing takes place whenever any push 
is performed since each push source has its own local register. The 
selection as to which is used is a function of the local register enables. 
The output of the relative push local register, like the other three 


registers which capture return addresses, is connected to the return 
address bus (FSTK@8-13). 


3.13.5 The absolute push local register (see lbd page 29d) 


Another push micro allows fourteen bits of the dbus to be saved in the 
return stack. At the end of any push step, BUSD(82-15) are captured in the 
absolute push local register. This register, like the other three 
registers which capture return addresses, is connected to the return 
address bus (FSTK@0-13). 


3.13.6 The hardware-interrupt address register (see lbd page 25) 


The hardware-interrupt address register (HWIA@9-13) captures the 
address to which the firmware sequence would have proceeded had an error 
(DSASTR) not been detected. This register, like the other three registers 


which capture return addresses, is connected to the return address bus 
(FSTK00-13). 


3.15.7 the return-address bus (see lbd pages 24m and 25m) 


The return-address bus connects together all four sources of return 
address. Constructed as a tri-state mechanism, the squrces are mutually 
exclusive. The bus operates under the following rules to supply a 
candidate return address to the next-address generator (see 3.14): 


1. If the most recent stack operation was a successful return, then 
the candidate for the next return is the return-stack local re- 
gister (KRAM@0-13). POPPED is generated in the step immediately 
following the successful return. Pulse-shaped via POOPED, it 
clears a 748175 chip. This 74S175 creates an enable for each 
of the four return address bus (FSTK98-13) sources. Clearing 


this chip enables the kram source and disables the three other 
sources. 


2. If the most recent stack operation was not a successful return, 
then one of the “push* sources is enabled to the return address 
bus. The register enabled is that which received the most recent 
push. The 74S175 is clocked (FSTKWE) by any push. When the clock 


occurs, one d input will be on: that corresponding to the type of 
push performed. . 
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When any push occurs, a new candidate for the next return is 
“stacked". The previous candidate (former stack top) is written into the 
detect stack memory via FSTIKWE formed from CDPUSH with a bit of pulse 
shaping. 2% 


[ 3.13.8 the stack overflow/underflow detector (see lbd page 24m) 


The stack overflow/underflow detector is a pal which monitors the 
address register (FWSTK9-3), the nature of the stack transaction (CDPUSH, 
_POPING) and an error detector enable. It generates two signals: 


@ 


1. a stack error was detected (STKOUT) which is connected to the 
syndrome register and to the DSASTR circuitry for causing 
an unprogrammed branch to firmware location zero (if FLAGC5=0) 


2. a stack underflow indicator which is connected to the syndrome 
register for distinguishing overflow from underflow. 


3.14 THE NEXT ADDRESS GENERATOR (block diagram identifier XIV) 


The next-address generator determines what the address of the next 
firmware location will be. One next address is as attainable as any other 
next address because the custom processor has no concept of address 
sequentiality. This flexibility is provided by devoting five firmware 
fields (29 control-store bits) to the task of deciding what control-store 
location shall next be executed. The control-store array is physically 
implemented as two 8192 location memories; the lower addresses access the 
else bank and the higher addresses access the if bank. Figure 5-1! diagrams 
the if and else next address generators. 


Of the five fields involved in this activity, the BR field code is the 
major determining factor distinguishing "“go-to’s"® from “‘returns® from 
"splatters" and deciding how the MK field will be applied. The TC field 
specifies which one of the 72 “conditions” shall be tested; when the 
condition is met, the if bank is enabled, and when the condition is not 
met, the else bank is enabled. 


3.14.1 bank selection (see lbd pages 23m, 29m and 28d) 


The TC field (CRIC@8-96) can specify one of seventy-two conditions to 
be tested in order to decide which bank shall be selected. Nine 74S151i's 
and three 74AS151's accept the seventy-two test conditions, the seven bits 
of the TC field and one bit of the next address field (CRNAGG) reducing 

7 | all this into one signal called TCTRUE. The high order next address bit 

ri specifies the test polarity which is why the firmware dictionary has twice 

[ as many (144) tests. The signal TCTRUE is.fed to four 7481498 drivers for 

distribution purposes. The drivers. are disabled if the firmware 

development facility is providing the control store output instead of the 
proms (TBRMEN). | 


3.14.2 else bank next-address generation (see lbd pages 5m, 6m, Sm, 12m, 
30m and 32m) 


The else bank may receive an address onto its tri-state address bus 
from one of three sources which are listed below along with the BR code(s) 
that enable(s) each source: 


else bank source BR code 
- 1. the next address field (CRNAQ1-13) 6,1,2,3,4,5,6,7,8,C.D 
2. the return stack (FSTK91-13) ) 
3. the firmware development facility (NAEB@1-13.EX) all 
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Note that the determination of which bank shall be selected is the 
responsibility of the TC field. 


Source #1 is the register which stores the thirteen control store bits 
_CSNA67-79 connected through tri-state drivers to the else bank address bus 
(NAEB@1-13). The drivers. are enabled by a 16R6A pal output (NA2ELS). The 
most significant bit of na (CRNAQ®) determines the polarity of the test 
condition. This bit is referred to as the BI field. 


Source #2 is the return-stack address bus (FSTK91-13) connected 


“through tri-state drivers to the else bank address bus. The drivers are 


enabled by a 16R6A pal output (RITNELS). 


Source #3 is the input which the firmware development facility employs 
when it forces the custom processor to start execution at some arbitrary 
address. The signal TBNASB imports the fdf-specified address and disables 
the other tri-state sources to the else bank address bus by disabling the 
pal and connecting to the pal output a 74S241 driver enabled by TBNASB 


whose inputs are biased to inactivate other sources of else bank 
addresves. 


3.14.3 if-bank next-address generation (see lbd pages 12m and 32m) 


The if bank. may receive an address upon its address bus (NAIBO1-13) 


from any one of six sources which are listed below along with the BR 
code(s) that enable(s) each source: 


if bank source address BR code(s) 
1. the next-address field (CRNAG1-13) ¢,8 
2. the return stack (FSTK@1-15) | 1,9 
3. the firmware development facility (NAIBO1-15.EX) all 
4. the 16-way masked splatter (SPLATA-D) | 2,3,4,5,6,7 
5. the 256-way unmasked splatter (PROC88-97) C,D 
6. the 16-way unmasked “break” splatter (BREK9@-07) Cc 


The if-bank address generator is divided into three partitions: that 
circuitry which develops bits 1 through 5, that circuitry which develops 
bits 6 through 9, and that circuitry which develops bits 19 through 13. 


3.14.5.1 if-bank address bits 01-85 (see lbd pages 12m and 32m) 


The five most significant bits of the address bus (NAIB@1-85) receive 
their inputs from one of three sources as shown below with the BR code(s) 
that enable(s) each source: 


eee _ 
ee en LENE RR eR, 


source for if-bank address bits 91-65 BR code(s) 


1. the next-address field (CRNAG1-@5) 6,2,3,4,5,6,7,8,C,D 
via one 74864 chip (NAIBG1) and 
one 74S248 section (NAIBO2-05.11) 
aoe hia by NA2IFH emanating from 
a pal. 


2. the return stack (FSTK91-05) 1,9 
via the 74S64 chip (NAIB@1) and 
portions of 748246 chips (NAIB82-05.RI) 
gear hee by RIN2IF emanating from 
a pal. 
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@ 3. the firmware development facility all 
| (NAIBO1-@5.ex) via TBNASB. Note that 


the drivers for this source are in 
the fdf. 


3.14.3.2 if-bank address bits 06-09 (see lbd pages 12m and 32m) 


The "middle* four bits of the if bank address bus receive their 


inputs from one of five sources as shown below with the BR code(s) that 
_, enable(s) each.source: ; | 


i 
[ 


source for if-bank address bits 06-09 BR code(s) 
1 


the next-address field (CRNAQ6-09) 9,2,35,4,5,6,7,8 
via a 7485240 section enabled by 
NA2IFM emanating from a pal. 


the return stack (FSTK86-099) 1,9 
via portions of 74S248 chips - 

(XATBO6--09.RI) enabled by RIN2IF 

emanating from a pal. 


0 


>. the firmware development facility all 
(NAIBO6-89.EX) via TBNASB. Note that 
the drivers for this source are in 
the fdf. 


[ 
’ 
' 
t 
q 
q \ 
[ 


4. the 256-way unmasked splatter (PROC00-@3) C,D 
via a 3632 prom enabled by BRPROC and 
no break splatter (BRKSPL). 


5. the 16-way unmasked break splatter 7 Cc 
- via a 748241 enabled by BRKSPL. 
Note that when a break splatter 
occurs, these four address bits 
| are forced off. | 


3.14.3.3 if-bank address bits 10-13 (see lbd page 13m) 


The four least-significant bits of the if-bank address bus receive 


six types of inputs as shown below with the BR code(s) that enable(s) each 
inputs 


source for if-bank address bits 198-15 | BR code 


1. the next-address field (CRNA190-13) 

Two elements are used to allow the four 

least-significant bits of the if/else al- 

ternatives in two-way branches to differ. 

These two elements are a 74S64 chip per | 7 ae | 

bit and a 74AS151 chip per bit (i.e., eight 

- total chips). The three low-order bits of the 

[ BR code select among the eight inputs of the 
74AS151. With a BR code of zero, “crna is selected 
: and sent to the 864 anded with the mask 

(CRMKO8-83). Another gate of the S64 ands 

mask with crna. The effect of these two gates 

is to allow the assembler, by controlling the 

mask field, to generate any four-bit value 

for the if bank as a function of the raw 

else-bank value. 
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2. the return stack (FSTK10-13) 1,9 
, The BR code selects input #1 on the 
| - 74AS151 (FSTK10-13) whose output is 
anded with the mask bit on the 74S64. : 
Another gate on the S64 allows the 
crna field through if the mask is off. 


This mechanism provides alternate 
returns. 


, “- |_ «sy. 3. ‘The firmware development facility all 
? (NAIB10-135.EX) via TBNASB which, after — 

disabling all other inputs, routes 

four bits through the 74S64's. 


4. the 256-way unmasked splatter (PROC04-07) C,D 
via a 3632 prom, enabled by BRPROC and 
no break-splatter, through the 74S64's. 


5. the 16-way unmasked break splatter via a | C 
74S241 enabled by BRKSPL and wire-or'd to 


the output of the 3632 prom, and connected 
to the 74S64's. 


The 74AS151’°’s are selected by the three. low- 
order bits of the BR code to choose among 
six types of sixteen-way splatters. The 
outputs of the selectors (SPLATA,5B,C,D) 

are anded with the mask bits on the 74S64's. 
Another gate on the 74S64 allows the crna 
bits through if the mask is off. In this 
manner, any combination of the four selec- 


tor outputs may participate in the splatter. 


[ 6. the 16-way masked splatters 225,4.5,6,7 
[ These splatters are: 


| splatter 7 BR céde 
[ a. four bits of aram address 


b. four t flags 
c. operand-type information 


d. four arithmetic indicators 
[ e. four outputs of the opmux 


YN nw? ww N 


f. four leading-zero indicators ; 
[ 3.15 AVAILABILITY CIRCUITS (block diagram identifier XV) 
, The availability circuits are of three types: 
[ 1. those that detect errors, 


2. those that generate check information so that other system elements 
might detect errors, and 


3. those that verify the integrity of the other two. 
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3.15.1 error-detection circuits 


Error detection requires that data, transmitted around the system, be 
accompanied by redundant information like parity or an error dectection 
and correction code (EDAC). Another mechanism for error detection is to 
recognize that a totally unexpected event occurred, such as receiving no 
response when attempting to communicate with another system element. 


The custom processor’s areas of error detection are listed below. 


, Subsequent paragraphs will discuss each area in further detail: 


1. procedure parity 
2. data parity 
3. procedure red (uncorrectable edac error) 
4. data red (uncorrectable edac error) 
5. procedure uar (unavailable resource) 
6. data uar (unavailable resource) 
7. stack overflow or underflow 
8. control store and pal parity 
3.15.1.1 procedure parity (see lbd pages 15m, 16m, and 34m) 


When procedure is delivered from the memory subsystem, 32 information 
bits are accompanied by 4 parity bits. These parity bits are captured (by 
PALOOK or PELOOK) in a register parallel to that which captures the 
procedure itself. In the meantime, the latched procedure bus (BUSP@0-15) 
is monitored by -two 74S288 parity checkers. The trick is to select the 
parity bits which correspond to the procedure bytes now on the pbus. This 
selection is performed by a pal which receives as input the 4 parity bits 
stored for “pa”, the 4 parity bits stored for "pe", and the take counter 
(resychronized to match the pal'’s needs) emitting a selected parity bit 
(PARP@9 and PARPG8S) for each 74S288. The output of the 74S2890 which 
monitors BUSP(8-7) is gate by PEKLFT when “left” procedure is sampled 
while the output of the 745280 which monitors BUSP(8-15) is gate by PEKRCT 
when “right” procedure is sampled ("peeked” or “taken"). 


In order to allow testing of procedure related hardware. both PEKLFT 
and PEKRGT are inhibitted in a firmware step containing a NOFALT micro. 
Otherwise PERPRC is sent to the general error collector DSASTR and to the 
syndrome register. ; 


. 


3.15.1.2 data parity (see lbd pages 32d, 33d and 27m) 


—_..When inra or inrb-is placed upon the zbus, stimuli coming from-a pal 
(NOFALT.DT) which decodes the field TC, gates the output of the 74S280 
parity checkers which monitor the four zbus bytes. Two pair of outputs are 
collected in PERDTL and PERDTR. The result (PERDAT) is sent to DSASTR and 
to the syndrome register. 
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3.15.1.3 procedure red (see lbd pages 16m and 27m) 


When procedure is delivered from the memory subsystem, 32 information 
bits are accompanied by 2 “red" indicators. These indicators, accusing the 
left 16 bits or the right 16 bits of containing an uncorrectable edac 
error are captured (by PALOOK or PELOOK) in a register parallel to that 
which captured the procedure itself. A simple selection is now required 
as a function of which procedure bytes are being sourced to the pbus. This 
selection is performed by a l16L8A pal which receives the two red bits 


_ stored for "pa", the two red bits stored for."“pe", and the take counter 


“(resynchronized to match the pal's needs). The error signal (REDPRC) is 
sent to the general error collector (DSASTR) and to the syndrome register. 


3.15.1.4 data red (see lbd pages 27m and 34m) 


When inra or inrb is placed upon the zbus, stimuli coming from a pal 
which decodes the ZB field, enables two sections of a 74S157 selector 
(REDDTL and REDDTR) which discover whether the left and/or right data 
words had good edac. The two data-red error signals are or'd (REDDAT) and 
sent to the general error collector (DSASTR) and tu the syidrome register. 


3.15.1.5 procedure uar (see lbd pages 16m and 27m) 


When procedure is delivered from the memory subsystem, 32 information 
bits are accompanied by 2 umavailable resource indicators. The "left" 
indicator means that the system resource addressed does not exist whereas 
if the left indicator is off, the “right” indicator means that the address 
delivered to the memory subsystem from adrp was the last one installed in 
this system. A pal samples the four error signals (PAUARL, PAUARR, PEUARL, 
and PEUARR) and determines whether an error (UARPRC) is to be sent to the 
general error collector (DSASTR) and to the syndrome register. 


3.15.1.6 data uar (see lbd pages 34m and 27m) 


When inra or inrb ts placed upon the zbus, stimuli coming from a pal 
which decodes the ZB field, enables two sections of a 74S157 selector 
(uardtl and uardtr) which discover whether the system resource addressed 
exists (i.e., a left uar) and whether the memory location provided to the 
memory subsystem from adra or adrb, while requesting four bytes, was the 
last address of installed memory (i.e., a right uar and no left uar). The 
outputs of these two sections (UARDTL and UARDTR) are or’d in UARDAT and 
sent to the general error collector (DSASTR) and to the syndrome register. 


3.15.1.7 stack overflow or underflow (see lbd page 24m) 


The stack overflow/underflow detector is a pal which monitors the 
address register (FWSTK9-3), the nature of the stack transaction (CDPUSH, 
POPING) and an error detector enable (FLAGC7). It generates two signals: 


1. STKOUT: a stack error was detected (i.e., a push was attempted and 
the stack was full, or a return was attempted and the stack was 
empty). This signal is connected to the general error collector 
(DSASTR) and to the syndrome register. 


2. STKUNW: a stack underflow error was detected (i.e., a return was 
attempted and the stack was empty). This signal is sent to the 
syndrome register to distinguish overflow from underflow. 


- 
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3.15.1.8 control-store parity (see lbd pages 5m, 6m, 8m, 9m, 11m, 
3d, 4d, 5d, 6d, 7d, 8d, 9d, 18d, and iid) 


The 128-bit control-store array contains one parity bit in each 
thirty-two. The parity bits are CSXX16, CSXX48, CSXX89 and CSXXB2. In each 
thirty-two-bit group, the control-register (cr) outputs are tested for 
correct parity. In some firmware fields, raw control-register flops do not 
exist because registered pals are used to perform "in-flight" decoding of 
the control-store output. In these instances, the pal(s) check(s) parity 
on the portion of the field in its purview and sends the result along with 


“"raw cr bits to a gaggle (14) of 7482808 parity checker chips. 


Parity chip EP9887 checks parity on the first nine control-store bits, 
EP6815 checks parity on the next nine (including the parity bit for this 
thirty-two-bit group), EP1623 generates parity for the next eight and 
accepts PORTLY as an input which represents the next three, and finally 
FWPAR@ gathers them all up along with PARTLY, which represents the last 
three. The error signal FWPAR® is sent to the general error collector 
(DSASTR) and to the syndrome register. — 


In the second group of 32 control-3tore bits, EP3239 checks parity on 
the first nine bits, EP4847 checks parity on the second nine bits 
including the parity bit for this group, EP4855 checks parity for the next 
nine bits and FWPAR! checks parity for the last five and gathers the 
outputs of the other three chips to form an error signal which is sent to 
the general error collector (DSASTR) and to the syndrome register. 


In the third group of 32 control-store bits, EP6472 checks parity on 
the first nine bits (CKPRIY gathers the first two), EP7381 gets the next 
nine including the parity bit for this group, and FWPAR2 gathers the 
remaining fourteen (four via BRPRTY, three via TCPRTY.13, and three via 
TCPRTY.46) in addition to accepting the output of the previous checkers. 
The error signal is sent to the general error collector (DSASTR) and to 
the syndrome register. 

In the fourth group of 352 control-store bits, EP96A5 checks parity on 
the only eight of this group (a pal gathers three bits into CRZBPB) which 
are on the daughter board, and sends this knowledge to the mother board 
where EPA8B6 checks parity on the next nine bits including the parity bit 
for this group, and FWPAR3 gets the last fifteen bits (three via FIPRTY, 
four via BSPRTY.93, and four via BSPRTY.47) in addition to gathering the 
contributions of the previous checkers. The error signal FWPAR3S is sent to 
the general error collector (DSASTR) and to the syndrome register. 


3.15.2 parity generation circuits (see lbd page 35d) 


When outr is loaded, four parity bits are created by four 74S288 chips 
which each examine one byte of the dbus and place the parity bit ina 
register loaded by the same signal as that which loads outr. These four 
parity bits accompany the data wherever its final destination may be 
(e.g., the memory, an i/o controller). See also 3.11.2. 


et on ee ee ee NN — a renee 


3.15.3 verifying the integrity circuits (see lbda pages 35d) 


When parity is generated on the dbus to accompany the data loaded into 
outr, the hardware provides a method of generating even rather than the 
conventional odd parity. This can be accomplished only if the processor is 
off-line (FLAGCO is off) and if FLAGC2 is on. This mechanism, in 
conjunction with the WRAP micros, allows a firmware routine (presumbly the 
quality logic test) to verify the integrity circuits by transferring data 
with both even and odd parity from outr to inra, from outr to inrb, from 
outr to pa and from outr to pe. | 
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The micro SYND is available to verify the integrity of the syndrome 
register by causing a simulated error, stimulating the general error 


collector (DSASTR) and sampling the presumably quiescent error sources 
into the syndrome register. : 


3.15.4 branch to sero (see lbd 27m) 


When the 74S133 (DSASTR) is stimulated, it sets SYRCLK at the start of 
the next firmware step. The leading edge of SYRCLK samples all error 


_sources into the syndrome register (SYND@8-31). During the first step 


following the detection of an error, the control flop FLAGC5 controls 
whether the flop DSTFF! will set leading toward the hardware interrupt. If 
FLAGCS if off, DSTFF! starts a chain of events which will cause location 
zero to be the next executed. The delay-line driver DSA006 starts an edge 
down the delay line DSA288 while, at the same time, the otherwise intended 
next address is being allowed to settle in the next-address generator. 
After 280 nanoseconds, DSIFF2 sets, clocking the intended next address 
into the hardware-interrupt-address register (HWIA90-13). A 180-nanosecond 
pulse is formed by HOLDIT which clears the next-address control-register 
flops (CRNAG9-13) and the test-condition muxes are disabled, forcing ar 
else bank enable. The next-address generator emits zero and the control- 
store array is accessed. A clock stall signal (WAITUP), which has been 


active through this entire ceremony, is allowed to relax and the content 
of location zero ‘is executed next. 
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FIRMWARE DESCRIPTION 


-4.0 FIRMWARE DESCRIPTION 


‘This section provides a detailed description of the 352 bit Custom 
Processor firmware structure. 


The custom rocessor divides its firmware word into thirty-one fields 
(see figure 4-1). The discussion that follows is organized into fourteen 
zones where the micros available in these zones are described one field at 
a time. Some fields contain no micros but serve merely as arguments for 
other micros. Some fields control more than one hardware element. The 
coder may not recognize that even though each hardware element appears to 
have a selection of micros, only one micro from one of the groups is 
allowed in each step. The fourteen zones are listed below with a brief 
description of the related hardware each zone controls: 


2 a ee ee ae eee oe 
ne errno ee 
oe NR A -- 
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SECTION FOUR FIRMWARE DESCRIPTION 
I. 29091 control The six fields which control the 2901 are 
AA, AB, AS, AF, AD, and ADE. 
II. ARAM control The two fields which control the ARAM are 
RM, and RW. 
III. D BUS control The five fields which control the D bus 
are DF, DG, DI, DJ, and DK. 
. - IV. S BUS control The fieid which controls the S bus is SS. 
V. 2 BUS control The field which controls the Z bus is ZB. 
VI. LOCAL BUS The field which controls the Local bus 
control is BS. 
VII. FLAG control The field which controls the TEMP flags 


is FT. The field which controls the PERM 
and CONTROL flags is BS. 


VIII. NIBBLE SHIFTER The field which controls the nibble Shift- 
control : er is SD. 
IX. INDICATOR The field which controls the loading of 
control both the arithmetic and miscellaneous 
indicators is ID. 
X. OP register The field which controls the loading 
control and modification of the OP register is 
OP. 
XI. LOAD control The fields which control the loading of 
other ot registers are LA, LO, LV and 
H and O 
XII. CLOCK control , The field which controls the Clock speed 
is CK. 

XIII. STACK control The field which controls which firmware 
address (if any) is pushed onto the stack 
is Ps. 

XIV. NEXT ADDRESS The five fields which control the value of 
control the next firmware address are BI, NA, TC, 
BR and MK. 


A field is a group of control store bits devoted to the control of a 
hardware entity. In general, a one bit field has one possible micro, a two 
bit field has three possible micros, a three bit field has seven possible > 
micros etc. In any firmware step, each field may contain only one micro. 
The design attempts to collect those micros which are naturally mutually 

“exclusive into the same field; e.g., in some step, the coder may wish the 
alu to add or he may wish it to subtract but aaa | not both. The 
firmware word format is depicted in figure 4-1. 
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$n tan pe ta ta tan ta $$ $$ $$ $$ H+ 
Daughter t AA i AB 1 AS | AF t . 
$n tan pa pa $a an panne tan ta $a $$ $$ = $$ HF 
88 3 7 11 15 


tao t--4-- $= $= $$$ Hon tt $$ $$ $$ + 
Daughter =e; AD «ADE t ID It{DFI DG | DI 
$a —$—— +--+ -- +--+ $$ $F HH HH + + + 

16 19 23 27 31 


tee tena nfo neta Fann fon tan to ta $a fae $e — $= $$ 
Daughter { DJ l DK l 
Se ee ee ee ee ee 

32 35 39 43 47 


eS ee a SD en Se Se Se Se Se Se Sa Se Soe See 
Daughter j =o | RM RW io} OP t 
| Pe ee ee eee ee ee ee ee ee ee ee Se Se See See See 

48 51 55 | 59 63 


a ee ee a a ee a a a a 

Mother 4 CK IBII NA ; i 
. a ee ee ne a ee ee 

64 67 71 75 719 


| eS a ae ee ee ee an ee a en an a ee ee en of 

Mother {= | TC | BR I MK ! 
Pe ee See er Sa a Oe Se Se Se See SD SoS SO SO SS 
898 83 87 94 95 


Seen eee coe en ee Do Do Pe 
Daughter ILVI ZB ILO! SD 1 
Sen cee ten ee ne Dn en eg 
96 99 185 
tea ten pen pa— te t-—+-- +--+ 
Mother i Ps !{ 1 FT it 


Hea te—$- 4-4-4 -- 4 -- +--+ 
184 187 111 


$a npn nfo FF $$ $$ $$ $$ ta tet 

Mother {#*] 5S I LA j BS t 
PS ae a ae a a a Se a on a Ss Sor ee Soe. Sore | 
112 115 119 125 127 


WHERE ** = F/W PARITY CHECKS 


FIGURE 4-1 
THE CUSTOM PROCESSOR FIRMWARE WORD FORMAT 
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SECTION FOUR 


FIRMWARE DESCRIPTION 


4.1 2981 CONTROL 


Six fields which control the 2961 register file and ALU: 


AA provides the four bits which select the register file a 
location available at the A port. The coder specifies the 
A-port address in an argument of an AS~field and/or AD 
field micro (see below). 


AB provides the four bits which select the register file 


location available at the B port. When the ALU output is to 


be retained, the AB field selects the register file lo- 
cation where the ALU output is stored. The coder specifies 


the B-port address in an areumeat ef an AS field and/or AD 
field micro (see below). 


AS selects two operands (r/s) for manipulation by the ALU from 
among five sources: the A port, the B port, the Q register, 


the D bus and zero. 


micro 


R:A'S:Q(AA) 
R:A'S:B(AA,AB) 


R:8'S:Q 

R:0'S:BCAB) 
R:6'S:A(AA) 
R:D'S:A(AA) 


R:D'S:Q 


R:D'S:8 


description 


the r input to the 
AA of the register 
the s input of the 
ister. 


the r input of the 
AA of the register 
the s input of the 
AB of the register 


the r input of the 
the s input of the 
register. 


the r input of the 
the s input of the 


‘AB of the register 


the r input of the 


the s 


AA of 


the r 
the s 
AA of 


the r 
the s 


the r 
the s 


input of the 
the register 


input of the 
input of the 
the register 


input of the 
input of the 


teste sede a EB UOR SS 


input of the 
input of the 


The available micros are: 


alu receives 
file. 
alu receives 


alu receives 
file. 
alu receives 
file. 


alu receives 
alu receives 


alu receives 
alu receives 
file. 


alu receives 
alu receives 
file. 


alu receives 
alu receives 
file. 


alu receives 
alu receives 


location 


the q reg- 


location 


location 


zero. 
the q 


zero. 
location 


zero. 
location 


the dbus. 
location 


the dbus. 
the q reg- 


alu receives 
alu receives 
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AF determines what manipulation shall be performed on the two 
operands provided by the AS field. The available micros 


are: — . 
micro the alu output receives: 
F:ADD1 the s input plus the r input plus one 
F:ADDC the s input plus the r input [plus one 
soe : if the carry indicator (ind!) is true]. 
F:ADDC! the s input plus the r input [plus one 
if the carry indicator (ind!) is false]. 
F:ADD the s input plus the r input. 
F:S-R the s input plus not the r input plus 
| one 
F:S-R-C° the s input plus not the r input [plus one 
| if the carry indicator (ind!) in on]. 
F:S-R-C the s input plus not the r input [plus one 
: if the carry indicator (indi) is off]. 
F:S-R-1 ‘the s input plus not the r input. 
F:R-S | the vr input plus not the s input plus one. 
F:R-S-C* _the r input plus not the s input [plus one 
if the carry indicator (indi) is on]. 
F:R-S-C the r input plus not the s input [plus one 
- if the carry indicator (indi) is off]. 
F:R-S-1 the r input plus not the s input. 
F:OR the s input inclusive ored with the r in- 
put. , 
F:SR the s input anded with the r input. 
F:SR° the r input anded with not the s input. 
F:XOR the s input exclusive ored with the r in- 
put. 
F:XNOR the s input exclusive ored with not the r 
input. 
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AD determines where the ALU output is to be retained within 
the 2901. The choices are the register file, the Q register, 
or neither. The AD field also allows any register file 
location to be presented to the zbus port. The AD field also 
controls the single-bit shifter. The 32-bit output of the 
ALU may be shifted one bit left or right and stored in the 
register file at location AB. The 64-bit output of the ALU 
and the Q register may be shifted one bit left or right and 
stored in the register file and Q. The available micros are: 


micro description 


Y:F'°Q:F the q register receives the alu output. 
the zbus control field may also select 
the alu output. 


Y:F the zbus control field may select the alu 
output. 


Y:A'B:F(AA,AB) the alu output is written at location AB 
in the register file. 
the zbus control field may select the data 
from the A port of the register file. 


Y:F'B:F(AB) the alu output is written at location AB 
in the register file. 
the zbus control field may also select the 
alu output. 


Y:F'BQ:FQSR the 64-bit concatenation of the alu output 
(AB, ADE) and the q register are shifted right one 
bit position. The shift-end-effect control 
(see ADE below) determines the value of 
the most-significant bit. 
the 32 most-significant bits of the shifted 
result are written at location AB in the 
register file. 
the 32 least-significant bits are written 
into the q register. 
- . the zbus control a select the 
alu output. 


Y:F*BQ:FQSL . the 64-bit concatenation of the alu output 
(AB, ADE) and the q register are shifted left one 

bit position. The shift-end-effect control 
(see ADE below) determines the value of 
the least-significant bit. 
the 32 most-significant bits of the shifted 
result are written at location AB in the 
register file. 
the 32 least-significant bits are written 
into the q register. 
the zbus control field may also select the 
alu output. 
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| micro description 
; [ Y:F'B:FSR the alu output is shifted right one bit 
| (AB,ADE) position. The shift-end-effect control 
| 


(see ADE below) determines the value of ~ 
the most-significant bit. 
| the 32 most-significant bits of the shif- 
ted result are written at location AB in 
the register file. 
_ the zbus control Etete may also select the 
[ GP ; alu output. - 
Y:F°B:FSL the alu output is shifted left one bit 
(AB,ADE) position. The shift-end-effect control 
i (see ADE below) determines the value of 
the least-significant bit. 
the 32 least-significant bits of the shif- 
ted result are written at location AB in 
[ the register file. 


the zbus control field may also select the 
alu output. 


into the ALU (for 32- and 64-bit shifts) and the bit which 
shifts into Q (for 64-bit shifts). There are six choices for 
insertion: the most- or the least-significant bit of the 
ALU, the most—- or the least-significant bit of Q, the one- 
bit value of Flagti (early), or a literal zero. Combinations 
are restricted to four for any given direction and length of 
shift. As an example, for a 64-bit circular left shift: 


; Y:F*BQ: FOQSL(AB, CIRC) 
4.2 ARAM CONTROL 


| ADE controls the "shift end effects"; 1. e.,the bit which shifts 


| Two fields control the ARAM: 


y RM determines which of the seven sources of ARAM addressing is 

to be used. Four of the sources are restricted to the first 
256 ARAM locations where RBR further isolates a group of 16 
and OPA, OPB, OPC, or OPD select one of those 16 to be ac- 
cessed. A twelve-bit literal may be used as an ARAM addres- 
sing source or the twelve-bit content of register RAR. The 
last ARAM addressing source allows the high 2948 locations 
of the ARAM to be used as a cache mechanism where eleven Z 
bus bits address the 2048-location ARAM block and informa- 
tion within the addressed location may determine hit versus 
miss as well as provide appropriate retained ‘waxuee which 
may be used for algorithm acceleration. 


[ RW determines which (if any) of the ARAM data bytes selected _ 
a —_—_—_———- —-- are to be overwritten. If RW=8, the content of the ARAM lo- 

- cation is left unchanged; otherwise, one or more bytes will 
[ be made equal to the value of the sbus-late. 


CUSTOM PROCESSOR TECHNICAL DESCRIPTION PAGE 4-7 


a 
[ 
in 
i 
i 
[ 
,. 


SECTION FOUR 


4.3 D-BUS CONTROL 


the D bus. 
interpreted. 


Byte(s) 


In general, 


FIRMWARE DESCRIPTION 


The D bus has many sources. The five fields discussed in this 
paragraph determine which source or combination of sources is allowed to 
The DG field specifies how the other four fields are ‘to be 


DF is a fill bit which is replicated where 
[ poeeeer to create 90 or FF bytes; DI has a bit 
: bus 


per byte specifying which 


shall receive the eight bit literal DK; DJ is sometimes a 


literal and sometimes a code choosing among many and varied D bus sources. 


°"4.3.1 DG=literal 


micro 


D: 007K 
D:FFJK 
D: JK99 


D: JKFY 
D: JKJK 
4.3.2 DG=broadside 
D: HEX 
D:HHPP 


byte w 
zeros 
ones 

DJ 
DJ 
DJ 


DK 
H 
DK 


D:O0P-BIT-AD zeros 


D:OPCD 


D:OPCD-X2 
D:OPCD-X2' 4 


[ 
[ 
[ D:0P 
; 
[ 


D:OPHSTRY 


D:PB!I 
D:PB2 


D:-PB2 


[ D:PCTR 


D:PHSTRY 


zeros 
DK 
DK 
DK 


zeros 


DK 
ones 
DK 
DK 


byte =z 
zeros 
ones 
DK 
DK 
DK 


DK 


zeros 
DK 
DK 
DE 

zeros 

zeros . 


ones 


The dbus is subdivided into 4 bytes named w, x, y, and zg. 


When DG=literal, DF, DI, DJ and DK provide five types of literals: 


byte y byte z 
DJ DK 
DJ DK 
zeros zeros 
ones ones 
DJ DK 


hex decoder 


procedure bus (90-15) 


OPA/OPB OPC/OPD 
DK 0,0,8,0PC(0-3),8 
OPC OPD 


$000000,0PC(9-3),0PD(9-3),9 

©800008,0PC(8-3),0PD(0-35),1 

OPA/B/C/D of previous step 
DK PBUS( 0-7) 
procedure bus (80-15) 
procedure bus (80-15) 


Program counter 


program counter at last rni 


D:RAMAD-X8 zeros 600000000000 ,DK(4-7,0),RAMAD(8-11),DK(1-3) 


D:RBR*RAR DK DK RBR(@-3),RAR( 8-11) 
[ D:Z z bus z bus z bus z bus 
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4.3.3 DG=mix 


Certain sources may, on byte boundaries, be mixed onto the 
dbus. These sources are the ARAM, ADRA, ADRB, or ADRP via 
the sbus-early; the Z bus via the shifter and the sbus- 
late; the H register; a literal byte (DK); a fill byte 
(DF). The micro D:: requires up to six arguments, the 
first four specify the source for bytes w, x, y and z, 
respectively; the fifth specifies the eight-bit literal 


. if any, and the sixth specifies the value of the fill byte, 


if any. 
4.3.4 DG=sign-extend 


Three sign extend micros are provided to place onto the 
D bus some right portion of the S bus with the most-si- 


genificant bit of that right portion replicated in all 
bits to the left. 


micro byte w byte x byte y byte z 
D:SEX8 8*sbus(24) 8*sbus(24) 8*sbus(24) sbus(24-31) 
D:SEX16 8*sbus(16) 8*sbus(16) sbus(16-23) sbus(24-31) 


D:SEX24 8*sbus(88) sbus(@8-15) sbus(16-23) sbus(24-31 ) 
4.4 SBUS CONTROL | 


One field, SS, controls which source is placed upon the 8S bus. This 
field allows two different sources onto the sbus in the same step. A 
“split cycle" is a firmware step in which the sbus receives from a 
different source during the early phase than it does during the late 
phase. Two types of split cycles are provided: the first sends ADRS 
(ADRA, ADRB, or ADRP) to the sbus during the early phase and the Z bus 
during the late phase, whereas the second sends the ARAM to the sbus 
during the early phase and the Z bus during the late phase. 


ae om enamored 
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micro Byte w byte x byte y byte z 


S:ADRA early adra(00-07) adra(68-15) adra(16-23) adra(24-31 
late adra(80-07) adra(08-15) adra( 16-23) Ree 


S:ADRA'Z early adra(00-07) adra(@8-15) adra(16-23) adra(24-31) 


late Z bus(80-31) nibble shifted by SD 
S:ADRB early adrb(@0-07) adrb(08-15) adrb(16-23) adrb(24-31 ) 
“ : late adrb(60-07) adrb(@8-15) adrb(16-23) adrb(24-31) 
S:ADRB'Z early adrb(@0-87) adrb(@8-15) adrb(16-23) adrb( 24-31 ) 

late Z bus(08-31) nibble shifted by SD 
S:ADRP - early adrp(00-07) adrp(@8-15) adrp(16-23) adrp(24-31 ) 


late adrp(00-987) adrp(08-15) adrp(16-23) adrp(24-31) 


S:ADRP'Z early adrp(00-87) adrp(@8-15) adrp(16-23) adrp(24-31) 
| late Z bus(00-31) nibble shifted by SD 


S:ARAM early aram(@-7) #1=aram(8-15) aram(16-23) aram(24-31) 
late aramn(98-7) aram(8-15) aram(16-23) aram(24-31 ) 


S:ARAM'Z early aram(0-7) aram(8-15) aram(16-23) aram(24-31 ) 


late Z bus( 08-31) nibble shifted by SD 
S:STK’ACCT early 8@,8,top of return stack, accounting timer 

late 8,8,top of return stack, accounting timer 
§:SYND early ? syndrome at latest dsastr or "synd"* 

late ? syndroms at latest dsastr or “synd” 
8:2 early Z bus(00-31) nibble shifted by SD 


late Z bus( 89-31) nibble shifted by SD 
4.5 Z BUS CONTROL 


The zbus may receive from any one of six sources. Two of the six 
sources are INRA and INRB which each may receive 32 bits of data from the 
outside world. Two flavors of INRA and INRB sourcing are provided. 

One flavor validates the parity on all four bytes, whereas the other 
validates the parity only on the leftmost two bytes. Another zbus source 
comes from an external element. This interface is intended for testing 


purposes only. The other three sources to the zbus are the ALU, the V 
register, and the dbus. 


micro byte w byte x byte y byte z 

Z:D DBUS(9-7) DBUS(8-15) DBUS(16-23) DBUS(24-31) 
Z:EXT FDF(@-7) FDF(8-15) FDF916-23) FDF(24-31) 
Z:V ¥(0-7) v(8-15) ¥( 16-23) ¥( 24-31) 
Z:¥ ALUY(@-7) ALUY(8-15) ALUY(16-23) ALUY(24-31) 
Z: INRA INRA(@-7) INRA(8-15) INRA(16-23) INRA(24-31) 
Z:INRB INRB(@-7) INRB(8-15) INRB(16-23) INRB(24-31) 
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4.6 LOCAL-BUS CONTROL 


The BS field controls the local bus. Thus, the BS field initiates data 
reads and writes, I/O reads and writes, and procedure reads. Data and 1/0 
reads and writes are explicit while procedure reads are implied by other 
micros, also in the BS field, which cause procedure bytes to be consumed 
by an incrementation of PCTR. If all this sounds complicated, it is. The 
initiation, monitoring, and consummation of local-bus activities requires 
reasonable care in the use of resources which may still be committed to a 

When an interlock is required, the cup will stall its 
clock automatically. It recognizes that a stall is required as follows: 


- 4. Stall unless and until at least two bytes are available in the 
prefetch buffer before entering any step which will examine or 
consume one or two such bytes; e.g., before entering a step 
which contains a PTAKE!, an OP:P4, a D:PB2, or an RNI micro. 


2. Stall unless and until the local-bus interface is quiescent be- 
fore entering a step which will initiate a new local-bus re- 


quest i.e., before enteri a step which contains a PREFETCH, 
a read (RD..), or a write (WR..) micro. 


3. Stall unless and until the local-bus interface is quiescent be- 
fore entering a step which will consume procedure bytes, if and 
only if the procedure buffer has at least four "empty" byte po- 


sitions; i.e. a step which contains a PTIAKE or an RNI’REFILL mi- 
cro. 


Other stalls must be stated explicitly as follows: 


1. Stall unless and until the local-bus interface is quiescent be- 
fore leaving a step which contains a STALL micro. 

2. Stall unless and until any outstanding non-procedural request 
has concluded before leaving a step invoking a “data stall”; 


i.e., before leaving a step which contains PEEK’STL or a 
PTAKE!1’STL, or a PTAKE2'STL micro. 


3. Stall unless and until the specified or implied input register 
has received the requested data before leaving a step invoking 
such a stall; i.e., before leavi a step which contains STALL-A 
(waits for new data to enter inra) or STALL-B (waits for new 
data to enter inrb) or micros of the form RD-..’STL(A/B). 


The BS field supplies the following local bus micros: 
micro description 


PEEK view one or two bytes of procedure whose memory 


addresses are petr and petr+1; verify parity. 
The two procedure bytes are available to be 


a --- loaded into OP or to be placed onto the d bus 
| or both. 


PEEK'STL same as peek, but stall before leaving this 


step until any non-procedural local—bus ac- 
tivity terminates. : 


PREFETCH stall before entering this step until all local 
. bus activity has concluded; then initiate a 
procedure read with the address in adrp. When 


the memory responds, place the four bytes into 
procedure buffers a, b, c, and d. 
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PTAKES same as peek, but stall before entering this 


step if the procedure buffer has space for 
four bytes and if so, initiate a four byte PrO= 
cedure request. 


mm LG 


PTAKE! same as PTAKE@, but add one to pctr. 

PTAKE1 'STL same as PTAKE!, but stall before leaving this 
= step if and until any non-procedural socanneus 
eee ae - activity terminates. 

PTAKE2 same as PTAKES, but add two to pctr. 

[ PTAKE2'STL - game as PTAKE!'STL, but add two to petr. 
| RD-2B(SA) stall before entering this firmware step until 
all local-bus activity has concluded; then ini- 
tiate a read request on the local bus, reading 
1 two bytes at memory addresses adra/b-adra/b+1. 
Inra/b(8-7) and (16-23) will receive the first 


byte and inra/b(8-15) and (24-31) will receive 
the second byte. 


RD-2B’STL(SA) same as RD-2B'(SA), but stall before leaving 


this step until the two bytes requested have 
arrived into inra/b. 


i 
[ RD-4B(SA) stall before entering this step until all lo- 
' cal-bus activity has subsided; then initiate 
read request reading four bytes on the local . 


| bus at adra/b, adra/b+!, adra/b+2, and 
| [ adra/b+3. 
aie RD-4B’STL(SA) same as RD-4B(SA), but stall before leaving 


this step until the four bytes requested have 
arrived into inra/b. 


RDLK-2B(SA) stall before entering this step until all lo- 
cal-bus activity has subsided; then initiate 
- @ read-and-lock-memory request on the local 
: bus. Note: ack must be tested before attemp- 
ting to remove data from inra/b. If ack is 
, not received, memory module was previouly lock- 
ed, indicating the resource was seized by ano- 
: ther requester. Note: any successful rdlk must 
| . be followed by either a rdul or a wrul micro; 
otherwise, the memory module will remain seized 
indefinitely. 


RDUL-2B(SA) stall before entering this step until all 
. local-bus activity has subsided; then initiate 

a read-and-unlock memory request on the local 
, | bus reading two bytes at memory addresses 
| adra/b and adra/b+1. Inra/b(6-7) and inra/b 
| (16-23) will receive the first byte; inra/b 

(8-15) and (24-31) will receive the 2nd byte. 

The memory module is released. 


CUSTOM PROCESSOR TECHNICAL DESCRIPTION PAGE 4-12 


SECTION FOUR FIRMWARE DESCRIPTION 


RD-IO(SA) stall before entering this step until all lo- 
cal-bus activity has subsided; then initiate an 
i/o read on the megabus, using adra/b(16-25) as 
the channel number and aara/b( 26-31) as the °- 
function code. If the channel acknowledges the. 
request, the data will be placed into inra/b 
(0-15). Note: ack must be tested before attemp- 
ting to remove the data from inra/b. 


ae : RD-LCL(SA) stall before entering this step until all lo- 
[ - cal-bus activity has subsided; then initiate a 
read local using adra(8-9) as the channel num- 

ber and adra(1@-15) as the function code. (For 
[ reading memory subsystem control information). 


REPLY(SA) stall before entering this step until all lo- 
cal-bus activity has subsided; then initiate a 
megabus request using adra/b(16-25) as the 
channel number and adra/b(26-31) as the func- 
tion code. Send outr(0-15) to the specified 
channel. 


WR-1B(SA) stall before entering this step until all lo- 
. cal-bus activity has subsided; then initiate a 
memory byte write request on the local bus. 
If adra/b is even, then outr(68-7) is written; 
- 42 adra/b is odd, then outr(8-15) is written. 


[ 


WR-1'°1B(SA) stall before entering this step until all lo- 
° cal-bus activity has subsided; then initiate a 
memory write request on the local bus. 
If adra/b is odd, then outr(8-23) is written; 
if adra/b is even, the results are unspecified. 


WR-1'°2B(SA) stall before entering this step until all lo- 
cal—-bus activity has subsided; then initiate a 
memory write request on the local bus. ss 
If adra/b is odd, then outr(8-31) is written; 
if adra/b is even, the results are unspecified. 


WR-2B(SA) stall before entering this step until all lo- 
cal-bus activity has subsided; then initiate a 
memory write request on the local bus. 
Outr(@-15) is written and adra/b(31) is assumed 


be zero! 
WR-2°1B(SA) same as WR-2B(SA), but outr(6-23) is written. 
: WR-4B(SA) game as WR-2B(SA), but outr(@-31) is written. 
[ aaa WR-I0(SA) |. stall before entering this step until all lo- 


cal-bus activity has subsided; then initiate a 
megabus non-memory request to the channel in 
adra/b(16-25) and the function code in adra/b 
(26-31). Send outr(0-15) to the specified 
channel. 


WR-LCL(SA) stall before entering this step until all lo- 
cal-bus activity has subsided; then initiate a 
local bus non-memory request to the channel 
adra(8-9) and the function code adra(108-15). 
Send outr(@-31) to the specified channel. 
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WRAP (BSA) copy outr(@-31) into inra(0-31), inrb(90-31), 
procedure buffers abcd, or procedure buffers 
efgh. Note: the coder is responsible for gua- 
ranteeing that the local bus is quiescent! ‘ 


WRLK(SA) stall before entering this step until all lo- 
cal-bus activity has subsided; then initiate a 
memory-write-lock request on the local bus. 

If the memory module was not locked, then 

P me ge,  outr(9-15) is written at adra/b, (adra/b31 

[ is assumed to be zero). If the memory module 

was previously locked, no data is written. 

The coder must test ack to determine which 

result occurred. Note: any successful WRLK 

must be followed by either a RDUL or a WRUL 
micro; otherwise, the memory module will remain 
seized indefinitely. 


WRUL(SA) stall before entering this step until all lo- 
cal-bus activity has subsided; then initiate a 
write-and-unlock memory request on the local 
bus. Outr(9-15) is written at adra/b (adra/b31 
is assumed to be zero). The memory module is 
released. 


4.7 FLAG CONTROL 


There are three groups of flags. Each group has eight elements for a 
total of twenty-four flags. They are: the eight permanent flags, the eight 
control flags, and the eight temporary =aee8 


4.7.1 Permanent flags 

Sixteen micros are dedicated to the eight permanent flags. There are 
no side effects which result from permanent flag actions. However, since 
the BS field controls the permanent flags, no local bus activity can be 
initiated in steps which set or clear permanent flags. Also, since the BS 
field allows consuming the procedure stream and local-bus transaction 
initiation, ptakes and setting or clearing of control flags are all 
mutually exclusive with modifications to the permanent flags. 


4.7.2 Control flags 


Sixteen micros are dedicated to the eight control flags. Each control 
flag is dedicated to a hardware entity. FlagC9 is dedicated to testing. 
} PlagCi and C2 are dedicated to testing only when flagC® is off. FlagC3 is 
[ dedicated to the accounting timer. FlagC5 allows the microcoder to ignore 

| hardware detected faults (e.g., memory parity). FlagC7 is dedicated to the 
return stack. Note that altering the state of a control flag is mutually 
exclusive with initiating local bus activity, viewing the procedure stream 
or changing the state of a permanent flag. 


~4.7.3 Temporary flags 


Seventeen micros control the temporary flags. Sixteen of them set or 
clear one flag while the seventeenth clears all eight temporary flags. 
flagTi has hidden effect in that it participates in controlling the shift 
end-effects of the ralu. flagt6 serves as the data written into the scram. 
P Micros which control the temporary flags are mutually exclusive with 
[ micros of the form RAR:N’S.. or RARE: 'N (loading rarh with a literal) or 

, PUSH-R (relative push) or RAMAD:LIT (addressing the aram with a literal). 
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4.8 Nibble-shifter control 


The field which controls the nibble shifter is SD. The nibble shifter 
rotates the 32 bits of the z bus from zero to seven places (any multiple 
ef four bit positions) and puts the result onto the s bus. The notion of 
left/right is provided in the dictionary for convenience. 


The SD field has no micros but instead provides an argument for those 
micros which allow the sbus to receive the zbus. 


_4.9.Indicator control 


The indicators are stored in two groups: the arithmetic indicators and 
the- miscellaneous indicators. The general structure encourages the coder 
to manipulate data in one step, storing the result of the manipulation in 


indicators and then, in a subsequent step, test the appropriate 
indicator(s) via either IP... or BR... micros. 


4.9.1 Arithmetic indicators 


There are six arithmetic indicators called ind(8-5). For the purpose 
of performing operations on data whose width is less than 32 bits, 
arithmetic indicator sensing can be partitioned to the rightmost 8 bits or 
the rightmost 16 bits or the rightmost 24 bits as well as all 32 bits. The 


argument (1id23) provides control of the partioning using convenient 
labels: 


dblw (doubleword) ind(8-4) are sensitized to the full width of 
the alu i.e., 352 bits. 


addr (address) ind(-4) are sensitized to alu(8-51); 
e.g., ind2 captures alu(8). 


word ind(9-4) are sensitized to alu(16-31); e.g., 
: ind3 becomes true if alu(16-31) are all zero. 


byte ind(6-4) are sensitized to alu(24-51); e.g., 


ind4 becomes true if alu(24-31) are all zero 
and ind3 is on. 


Arithmetic-indicator partitioning has no effect on indS since it 
monitors only the least significant bit of the z bus [z(31)]. Overflow 
(ind®) is intended for add or subtract operations and furthermore lives up 
to its name only in two's complement arithmetic. Ind@ becomes true if the 


carry into the leftmost bit (as partitioned) does not match the carry out 
of the same bit. 


4.9.2 Miscellaneous indicators 


The miscellaneous indicators are all stored in one “register” but may 
be thought of as four separate groups. The one indicator (ind6) which 
stores the output ofthe stop-code ram is the simplest of the lot. Note 
that the stop-code ram is addressed by byte y of the dbus. The second 
group, ind(7,8) are dedicated to detecting frame-bound crossings where a 


frame is a 51i2-byte contiguous block of memory, starting at any multiple 
of 512 bytes. 


ind6 the stop-code ram indicator stores the output 
of the stop-code ram as addressed by dbus 
(16-23). 

ind7 frame-bound indicator #7 becomes true if dbus 


bits 15 through 22 do not match zbus bits 
15 through 22. 


CUSTOM PROCESSOR TECHNICAL DESCRIPTION PAGE 4-15 


i 
me 
[ 

[ 

: 


SECTION FOUR FIRMWARE DESCRIPTION 
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inds frame-bound indicator #8 assumes the addi- 
tion of three values: a base address, a dis- 
placement, and an operand length where: 
the base address is ina ralu register, ° 
the displacement is on the d bus, 
and the operand length is in type(@,1) where @9 
ig length one, 91 is length two, 19 is length 
four, and 11 is length six. 
Ind8 becomes true if the three way add would 


2 : produce a carry out of alu bit 23. 


Note that ind#8 operates equally well if the 
ralu register contains the displacement and the 
dbus has the base address. 


The next indicator group contains one indicator which becomes true if 
zbus bits 8 through 28 match sbus bits 16 through 28, respectively. With 
careful planning, the hash indicator permits detection of a “hit” by 
addressing the aram with zbus bits 19 through 29, and placing the aram 
data onto the sbus for viewing by this indicator. 


ind9 hash-hit indicator becomes true if zbus bits 
8 through 28 are equal to sbus bit 16 through 
238. 


The last indicator group provides a mechanism for detecting the 
postion of an operand‘s most-significant nibble. 


ind(16-13) the leading-zero indicators store the number 
of leading zeros at the output of the alu. 


Micros which appear to allow less than the complete set of 
miscellaneous indicators to be stored are provided merely to inform the 
automated clock speed calculation program of the coder's intent since 
setting the clock speed to allow for the slowest of the eight would be an 
unnecessary performance sacrifice. 


4.19 OP-REGISTER CONTROL 


The OP register is a sixteen-bit register intended as long-term 
storage for interesting nibbles of the procedure stream. Since each of the 
four nibbles of OP may be incremented or decremented and since each nibble 
may be tested for containing extreme values, each is well suited 
to provide loop closure functions. For this reason (and others), OP may be 
loaded from various nibbles of the sbus. The multiplexer which selects 
what data is presented to the opa register inputs is also made available 
for branching upon. Thus, sixteen-way branches are available on any pbus 
nibble or on any sbus nibble (see paragraph 4.14). 
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Those OP-register loads which capture nibbles of the instruction 
Stream are: 


micro description 
OP:P¢ opa receives pbus(@-3), opb receives pbus( 4-7), 
. ope receives pbus(8-11), opd receives pbus(12-15) 
35 OPA:P¢@ opa receives pbus(@-3) | 
OPA:P4 opa receives pbus( 4-7) 
q | OPA:P8 opa receives pbus(8-11) 
OPA:P12 opa receives pbus(12-15) 
| OPB:P¢ opb receives pbus(9-3) 
| OPB:P4 opb receives pbus(4-7) 
‘ OPB:P8 opb receives pbus(8-11) 
OPB:P12 opb receives pbus(12-15) 
OPC:P¢ ope receives pbus(0-3) 
OPC:P4 ope receives pbus( 4-7) 
OPC:P8 . opo receives pbus(8-11) 
, OPC:P12 ope receives pbus(12-15) 
OPD:P¢ . opd receives pbus(@-35) 
| | OPD:P4 opd receives pbus( 4-7) 
| OPD:P8 opd receives pbus(8-11) 
OPD: P12 opd receives pbus(12-15) 
| OPA'B:P9@ opa receives pbus(@-3), opb receives pbus( 4-7) 
OPA’B:P8 opa receives pbus(8-11), opb receives pbus(12-15) 
OPC’'D:P¢@ ope receives pbus(0-5), opd receives pbus( 4-7) 


OPC'D:P8 ope receives pbus(8-11), opd receives pbus(12-15) 
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4.18.2 Sbus to OP 


The OP-register micros which capture nibbles of the sbus are: 


micro description 


OP:S3d opa receives sbus(0-3), opb receives sbus(4-7), 
ope receives sbus(8-11), opd receives sbus(12-15) 


oo yt Oe OP :S16 opa receives sbus(16-19) opb receives sbus(28-23) 
[ ope receives sbus(24-27) opd receives sbus(28-31 ) 
: OPA:SS opa receives sbus(0-3) 
OPA:S16 opa receives sbus(16-19) 
OPB:S4 opb receives sbus(4-7) 
: OPB:S2a opb receives sbus( 20-23) 
[ OPC:S8 ope receives sbus(8-11) 
opc:S24 ope receives sbus(24-27) 
[ OPD:S12 opd receives sbus(12-15) 
OPD:S28 ope receives sbus(28-31) 
[ OPA'B:S@ opa receives sbus(9-3), opb receives sbus(4-7) 
OPA'B:S16 opa receives sbus(16-19),opb receives sbus(20-25) 
( [ OPC'D:58 ope receives sbus( 8-11),opd receives sbus(12-15) 
‘ OPC'’D:S24 ope receives sbus(24-27),opd receives sbus(28-31) 
[ 
[ 
[ 
{ 
[ 
[ ; 
[ 
| | 
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4.18.3 OP increment/decrement 


The OP-register micros which increment or decrement an op register 


are: 
[ micro description 
: OPA-DEC opa receives opa minus one (if opa was zero, 
= test condition opa-wr becomes true). 
[ _ *S OPB-DEC opb receives opb minus one (if opb was zero, : 
: test condition opb-wr becomes true). 
? OPC-DEC | ope receives ope minus one (if ope was zero, 
| test condition opc-wr becomes true). 


OPD-DEC opd receives opd minus one (if opd was zero, 
test condition opd-wr becomes true). 


OPA-INC opa receives opa plus one (if opa was F, 
test condition opa-wr becomes true). 


OPB-INC opb receives opb plus one (if opb was F, 
test condition opb-wr becomes true). 


OPC-~INC ope receives ope plus one (if ope was F, 
test condition opce-wr becomes true). 


OPD-INC opd receives opd plus one (if opd was F, 
test condition opd-wr becomes true). 


4.11 LOAD CONTROLS 


Many registers are found lurking on the ends of buses just waiting for 
an opportunity to snarf up the data therefrom. These registers are adra, 
adrb, adrp/pctr, outr, v, h, rar, and rbr. 


=a eR 
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4.11.1 Loading adra, adrb or adrp/pctr 


 £ Adra may be loaded from the sbus or may be incremented by four or may 
' decremented by four. The same applies to adrb. Adrp may te loaded from 
the 


sbus three different ways. Micros which load adrp also load pctr. The 
applicable micros are: 


micro | description 
as ADRA:S adra(@8-51) receive sbus(60-31). 
=e ; ADRB:S adrb( 60-31) receive sbus(00-31). 
ADRP:S Sate teecsy) receives sbus(00-31). 
petr(00-31) receives sbus(8d-31 ) 
| [ ADRPE:S adrp(@6-22) receives sbus(00-22) 
: | petr(96-22) receives sbus(00-22) 
| ADRPL:S adrp(23-31) receives sbus(23-31 ) 
[ petr(23-31) rec.ivsca sbus(23-3!1) 
ADRA-DEC adra receives adra minus four 
[ ADRB-DEC °- adrb receives adrb minus four 
| ADRA: INC adra receives adra plus four 
é ADRB-INC adrb receives adrb plus four 
[ 4.11.2 Loading of outr, v, or h 
= The micros which load these registers are: 
: [ micro . description 
nd OUTR:D outr(¢6-31) receives dbus(00-31) 
[ V:Z v( 00-31) receives zbus(60-31) 
H:8 h(008-31) receives sbus(@0-31) 
[ ‘ 
[ 
[ 
[ . 
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4.11.3 Changing rbr 


Rbr is a four-bit register which can participate in addressing the 
aram. When opa, opb, opc, or opd provide the low nibble of ramad, rbr 
provides the middle nibble. The micros which load or change rbr are: — 


micro description 
RBR:SO rbr receives sbus(6-3) 
: RBR:S8 rbr receives sbus(8-11 ) ; 
RBR:S16 rbr receives sbus(16-19) 
RBR:S24 rbr receives sbus(24-27) 


RBR'RAR:SO rbr receives sbus(90-3), rar receives sbus(4-15) 
RBR’RAR:S16 rbr receives sbus(16-19), rar receives sbus(20-31 ) 
RBR-DEC rbr receives rbr minus one 

RBR-INC ror receives rbr plus one 


4.11.4 Changing rar 


Rar is a twelve-bit register which may be used to address the aranm. 
It is subdivided into a four-bit register (rarh) and an eight-bit register 
(rarl). Either registers may be incremented or decremented. 


4.11.4.1 Loading all of rar 


The micros which load rar, other than those of paragraph 4.11.3 are: 
micro description 


RAR:N'’S@(FT) rarh receives a four-bit literal (FT), 
rarl receives sbus( 8-7) : 


RAR:N'S8(FT) rarh receives a four-bit literal (FT), 
| rarl receives sbus(8-15) 

RAR:N'S16 rarh receives a four-bit literal (FT), 
rarl receives sbus(16-23) 


RAR: N'°S24 rarh receives a four-bit literal (FT), 
rarl receives sbus(24-51) 


RAR:S4 rar receives sbus(4-15) : 
RAR:S20 rar receives sbus(20-31 ) 
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4.11.4.2 Changing rarh 


The micros which or changes of rarh, other than those previously 
mentioned are: 


e 


micro description 


RARH:N( FT) rarh receives a four-bit literal (FT) 


. RARH:S4 rarh receives sbus(4-7) 
~ & RARH:S12 rarh receives sbus(12-15) : 
RARH:S20 rarh receives sbus(20-23) 
[ RARH:S28 rarh receives sbus( 28-31) 
RARH-DEC rarh receives rarh minus one 
[ RARH-INC rarh receives rarh plus one 
' 


4.11.4.3 Changing rarl 


The micros which change rarl, other than those previously mentioned 


[ are: 
3 micro description 
[ RARL:S@ rarl receives sbus(9-7) 
RARL:S8 rarl receives sbus(8-15) 
i ¥ RARL:S16 rarl receives sbus( 16-25) 
. | RARL:S24 rarl receives sbus( 24-31) 
w RARL-DEC rarl receives rarl minus one 
[ : RARL-INC rarl receives rarl plus one 


4.12 CLOCK CONTROL 


| A preprocessor to the firmware assembler determines what speed each 
: firmware step should be, by examining the microcode source. The microcoder 


seldom has reason to explicitly state the clock speed. For completeness, 
the clock micros are listed belows 


micro ' description 
C( VF) very fast clock ~ 105 nanoseconds. 

a C(HF) “half fast clock - 125 nanoseconds 
C( HL) half long clock - 145 nanoseconds 


c( VL) very long clock - 175 nanoseconds 


[ 
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4.135 STACK CONTROL 


The | return stack may contain up to seventeen firmware return 
addresses. The return stack operates as a last-in-first-out (LIFO) 
mechanism, allowing sufficient levels of nesting for most applications. 


The coder may push firmware addresses onto the return stack in one of 
three ways: 


micro description 


-  PUSH-D return stack receives dbus(02-15); i.e., an abso- 
lute address which occupies the dbus in this step. 


PUSH-R return stack receives an if bank address relative 
to the value in the next-address field but may 
differ from the next address field in the five 
least significant bits. 


PUSH-HWIA when a hardware detected error occurs, an unpro- 
grammed branch to firmware location zero occurs. 
The hardware remembers what location was otherwise 
d=stined for execution in a register called hwia. 
This micro allows the captured address to be pla- 
ced onto the return stack so that the routine 
which was interrupted may be resumed. 


4.14 NEXT-ADDRESS CONTROL 


Five fields control which of the 16384 firmware locations is next to 


be executed. Before each field is discussed, it is first necessary to 
expose some general information. 


Firmware steps are identified by a 14-bit “control store address" 
(CSA) and optionally a mnemonic label. In the discussion that follows, 
“CSA® is used instead of "“CSA/LABEL"® but it should be understood that 


restrictions applicable to a CSA (e.g., must be an IF-bank address) are 
equally applicable to the label. 


The 16384 location firmware array is divided into two banks. The first 
8192 locations, 0000 through IFFF (hex), constitute the ELSE bank. The 
last 8192 locations, 20900 through 3FFF (hex), constitute the IF bank. 


Firmware sequencing in the custom processor is never implicitly nor 
arithmetically determined. Every step specifies its successor or choice of 
successors. There are numerous ways in which the coder may specify what 
firmware location is next to be executed and they are best exposed 


by explaining each of the five fields which control firmware sequencing: 
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field explanation 


BI branch invert - a one-bit field which controls the 
polarity of the test condition. 


NA mext address - a thirteen-bit field which, in its 
simplest form, specifies which of the 8192 loca- 
tions of the bank specified by BI is next to be 
executed, as in the micro GOTO(STHEDEVIL). 


TC test condition - a seven-bit field which allows the 
coder to specify that the next step shall be a loca- 
tion in the IF bank or a location in the ELSE bank 
as determined by the result of testing one of seven- 
ty-two unary indicators 
(e.g., IF-I-ZRO(SFAIR, SRAIN) 

In this example the addresses of SFAIR and SRAIN are 
required to have the following relationship: 


1. SFAIR must be in the IF bank 
2. SRAIN must be in the ELSE bank > 


3. Their addresses may not be different except 
in the most-significant bit (from 1 and 2 
above) and the four least-significant bits. 
(i.e., if $FAIR is in a particular "block" 
of sixteen locations in the IF bank, then 
SRAIN must be in the corresponding sixteen- 
location block in the ELSE bank. 


The result of all this is that if the arithmetic in- 
Gicator I-ZRO was on, $FAIR will next be executed; 
if the arithmetic indicator I-ZRO was off, S$RAIN 
will next be executed. . 


MK mask - a four bit field which serves many purpo- 
ses. One of the purposes is best described here 
while the others can wait for the BR field: 


When the coder has specified a simple choice 
between IF and ELSE, MK identifies which of 
the four least-significant bits of the alter- 
native addresses differ. For instance if, in 
the previous example S$FAIR had been allocated 
CSA 2348 and S$RAIN. had been allocated CSA 
O34F, the assembler (not the coder) would set 
the value of the MK field to F indicating 
that all four least-significant bits of the 
-alternative addresses differ and the hardware 
does the rest. 


CUSTOM PROCESSOR TECHNICAL DESCRIPTION PAGE 4-24 


SECTION FOUR FIRMWARE DESCRIPTION 
P BR branch - a four-bit field which determines how the 
[ : succeeding firmware step shall be chosen. It permits 
the coder a veritable plethora of mechanisms for de- 
ciding the value of the next CSA as follows: ° 
[ mechanism description 
GO-TO( $SNOW) | specifies an unconditional suc- 
cessor 
[ ~ ; IF-224( 23454 , 04527) specifies a two-way choice as a 


function of the value of zbus bit 
24. If 224 is on, then 2345 is 
executed next; otherwise, 452 is 
executed next. 


RETURN specifies that the succeeding step 
is that CSA at the top of the 
seventeen-level return stack. 


[ RETURN’ (9) specifies that the succeeding step 
| is that CSA at the top of the 
Po seventeen-level return stack 
[ | . but with the two-weight bit and 
the four-weight bit set equal to 
ae zero (masked by FFF9). Here the MK 
, field contains the four least- 
[ significant bits of the mask and 
the hardware sets the other mask 
bits to ones. 


IP-ACK RETURN-OR(SDONT) specifies that the succeeding 
step is that CSA at the 
top of the seventeen-level re- 
turn stack only if the ACK indi- 
cator is on. If the ACK indicator 
is off, the succeeding step is 
SDONT. Note that SDONT must be 
in the ELSE bank, thus it is ad- 
| vised that CSA‘s pushed onto the 
: return stack be if-bank addres- 
| ses only. Note also that a condi- 
tional masked return of the form: 
IF-ACK RETURN’-OR(A,SDONT) 
is also provided (a conditional 
masked return. 
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BR-ARITH(9,3216#) specifies that the succeeding 
step is to be one of four as a 
function of the condition of two 
arithmetic indicators; namely, 
I-SGN and I-ODD. If they are 
both off, location 32198 will be 
next executed; if I-SGN is off 
and I-ODD is on, location 3211 
will be next; if I-SGN is on and 

re ‘ } I-ODD is off, location 3218 will 

Be be next; if they are both on, 

location 3219 will be next. Note 
that this mechanism permits the 
examination of two other arith- 
metic indicators. By specifying 
a mask with a four-weight bit, 
I-ZRO may be examined, and by 
specifying a mask with a two- 
weight bit, the dynamic alu car- 
ry may be examined. Note also 
that a conditional version, of 
the form: 


[ IF-Z'Z BR-ARITH(4,$CLOUDY) 


is also provided. 


BR-FLAGS(F, 34504) specifies that the succeeding 
step is to be one of sixteen 

in the block of if-bank loca- 
tions starting at 3458 as a 
function of four temporary flags 
(to, ti, t2, and t3). Note that 
a conditional version of the 
form: 
IF-~POOFP BR-FLAGS(6,$BANG) 


1 is also provided. 


BR-P6(D,2ABG# ) specifies that the succeeding 
step is to be one of eight in 
the block of addresses starting 
at location 2AB@ as a function 
of pbus bits 8, 1, and 3. Note 
that a conditional version of 
the form: 

3 IF-FLAGP1 BR-PO(E,$WIT) 
F is also provided. Note also that 

[ the BR mechanism may examine the 

other three pbus nibbles with e- 
qual alacrity. ; 
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P BR-S8(5,$SLEET) specifies that the succeeding 
[ step is to be one of four in 


the IF-bank block in which 

$SLEET resides, as a function of 
sbus@9 and sbus!1!1. Note that a 
conditional version of the form: 
IF-NOT-OPA-WR BR-S8(A,$SSLUSH) 

is also provided. Note also that 

[ i . the BR mechanism is available to “A 


— : examine any of the other seven 
sbus nibbles. 


BR-SCALE(F, SSUNNY ) specifies that the succeeding 

step is to be one of nine in 

| [ the IF-bank block in which 

u SSUNNY resides as a function of 

the leading-zero indicators 
(ind 10 through 13). In this 

[ case the number of destinations 
is limited, not by the mask, but 

by the fact that the leading 

zero indicators may store only 

nine unique values. Note that a 

conditional version of the form: 

IF-RUPT BR-SCALE(F,SSMILE) 

is also provided. 


—. pa 


BR-TYPE(3,222C#) specifies that the succeeding 
step is to be one of 4 (222C, 
222D, 222E, or 222F as a funce 
tion of the two type-register 
bits. Note that other mask 
values allow examination of 
I-ODD and sbus0@. Note also that 
a conditional version of the 
form: 

IF-NOT-BREAK BR-TYPE(F,SSPLASH) 
is also provided. 


[ 
= 
1 
|, 
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BR-PROC(2,$BEGIN) specifies that the succeeding 
step is to be one of 256 IF-bank 
locations. The $BEGIN CSA is 
used as a base address. A subdsti- 
tution of the eight least-signi- ' 
ficant bits emanates from an op — 
code decode unit. This unit is, 
in essence, a table look-up me- 
chanism which contains sixteen 
tables selected by the mask 

— ; field (in this case, table #2 

= is selected). The value : 

from the table becomes the out- 
put of the opcode decode unit. 
This splatter mechanism is in- 
tended to permit 16 different 
interpretations of procedure 
stream bytes (e.g., based upon 
poet isa). 
When this micro becomes part of 
the combinatorial micro “RNI” 
the existance of a BREAK over- 
rides the splatter on pbus, and 
instead performs a 16-way branch 
on the four sources of BREAK. 
In this application, the first 
16 locations of the splatter 
must be reserved. 


[ 
' 
[ 
" 
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[ 


ana 


® a 2 i 


—_ pene 


~ Pes 


CUSTOM PROCESSOR TECHNICAL DESCRIPTION : PAGE 4-28 


SECTION FOUR | | FIRMWARE DESCRIPTION 


4.15 AVAILABILITY 


The custom processor has many availability features which insure that 
processing proceeds error free. Some of these features test parity of 
incoming data, some check integrity data delivered to the custom processor 
from other system elements, some test the validity of the control-store 
array, and some generate parity to accompany output data, so that other 


system elements may verify that the data sent arrived intact. The list of 
availability features follows: 


o =~ 


4. data and procedure parity checks - whenever information is 
sourced from an input data register (e.g., Z:INRA) or from 


a procedure buffer (e.g.,PTAKE!1), parity is checked on the 
appropriate bytes. 


? 


data and procedure edac errors - whenever information is 
‘sourced from an input data register (e.g., Z:INRB) or 

from a procedure buffer (e.g., D:PB1), any uncorrectable 

memory error associated with the information is detected. 


Vw N 
e ® 


stack checks - whenever return addresses are added to (e.g., 
PUSH: $SHOVE) or removed from (e.g.,RETURN) the stack, a full 


or empty condition, respectively, may optionally be treated as 
an error. 


= 


control-store array checks - a parity bit is imbedded in each 
32 bits of control-store data. During each firmware step exe- 
cuted, four separate parity checks are performed to validate 
the integrity of the control-store read-out. 


5. parity generation — parity generation for the control-store 
array is performed by the assembler. Parity generation for 
data destined for other system elements via outr is performed 
when outr is loaded from the dbus. In order to verify the inte- 
grity of the parity generation and checking circuits, a mecha- 


nism is available in test mode for generating both even and odd 
2 parity. 


[ 


6. self testing - as part of every system initialization, the cus- 
tom processor executes a sequence of firmware routines whose 
purpose is to detect any hardware fault, either in the proces- 

sor or in the memory subsytem. This routine utilizes the inte- 
grity features mentioned above and take advantage of the syn- 
drome register and the hardware interrupt register. The syn- 
drome register captures the reason code for any hardware 

[ detected error and the hardware-interrupt-address register 


captures the next address intended had the interrupt not oc- 
curred. : | 
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THE NANOSECONDS 


™» 


5.0 THE NANOSECONDS 


The assembler rejects micro-op combinations which would result ina 
Clock speed ouside the range of the longest clock setting. The purpose of 
this section is to help explain how the “gear” is selected. 


The diagram of 5-1 is a representation of the custom processor 
oriented toward the subject of nanoseconds. In essence, the assembler 
contians a model which depicts the information of figure 5-1 along with a 
definition of each clock speed (i.e., 105ns, 125ns, 145ns and 175ns). 


The subject shall be approached as follows: 
first, a detailed explanation of the symbols used in figure 5-1; 


second, an explanation of why some paths have multiple symbols and, 
in general, how the reader handles choices; 


and last, an example of how one converts a set of micros into a number 
of nanoseconds. 


5.1 the symbology 


Clearly, for performance reasons, it is desirable for every step to be 
a VF step. Figure 5-1 illustrates those paths which might prevent the 
desirable but does not illustrate those paths which cannot impact the 
clock. An example of this point is shown in the table labeled “next 
address”. Notice that only two of the seventy-two test conditions are 
listed. This is because the other seventy will each succeed at performing 
its appointed function (bank selection) in no more than 105ns. 


Values in squares or non-squares are nanoseconds and abide by the 


| following rules: 


1. squares contain the number of nanoseconds from the beginning of 
the firmware step until the data, at the point where the square 
is located, is valid. This number means something only if the micro 
combination require the data path and can be ignored otherwise. 


2. non-squares (mostly circles) contain the number of nanoseconds the 
data must pay in order to propagate through. 
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5.2 the choices 
Choices are essentially of two types: 


1. depending upon the micro combination, the nanosecond value from 
the beginning of the firmware step may or may not be determined. 
A simple example of this is both the input and the output of the 
box called "PCB". Its input is valid at nanosecond 16 unless the 
aram address mux has the zbus selected in which case the output of 
the aram address mux is valid 6ns later than the zbus. That means 
that the output of the PCB box is valid at nanosecond 38 if the 
aram address mux isn’t selecting the zbus but if it is, then the 
output of the PCB box is valid 15ns after the zbus. 


[ 
| 


} 


- 
‘ 


@ non-square contains conditions. A simple example is the path 
through the alu oval. If the alu is required by the F:... micro 
to perform an arithmetic operation, then the data must pay 67.5ns 
to pass; otherwise the cost is only 25ns. 


nN 


5.3 putting it together 


In the step: 


R:A’S:B(@,6@) 
F:ADD 
IND: DBLW 


sail | 


The first micro specifies the two alu sources to be the two ports of 
the register file. The second micro specifies that the alu shall add. The 
third micro specifies that the arithmetic indicators shall be loaded. 


In figure 5-1, the rectangle labeled "ram" is signified to have its 
output valid at nanosecond 16 (from the beginning of the step). From 
there, the alu is encountered where, because an add is to be performed, 
the 16 must be increased by 67.5ns. Leaving the alu and heading for the 
indicators, it is necessary to select another addend which, since the alu 
operated arithmetically, is 25.5ns. The subtotal (16+67.5+25.5) is 189ns 
which, to arrive at the total, must be increased by 18% to account for 

non-silicon delays (i.e., media). This yields 119.9 which requires a clock 
setting of 125ns namely, an HF “box”. 


ee es 
® 


ry 
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In a more complicated step, where there are multiple end points, it is 
necessary to analyze each path in order to discover the longest one. The 


np pale of the step is determined by. the longest path. An example is shown 
elow: . 


MICRO 


CUMUL 

RD-45(ADRA) 8.0 
RAMAD : RAR 16.0 
. S:ARAM’Z ; 56.0 
? D::(K,A,A,A,,34) 62.0 
OUTR:D 96.9* 
R:D'S:A(3) F:ADD Y:F'BQ:FQSL(2,0PEN) 146.5* 

Z2:Y 131.5 

V:Z 136.5 
IND-D:Z 146.0 
OPC*D:P8 48.0* 
S:ARAM'Z (again) 143.5 

H:S 148.5* 
ADRB:S 159.6* 
IF-NOT-BREAK BR-PROC(7,SNOWAY) 133.5 


*zend point 


In this step, RAMAD is valid at 16, the ARAM readout is valid on the 
sbus at 56 , and the dbus receives twenty-four bits of the sbus at 62 and 
eight bits at 38 from the literal source. The first end point, OUTR, is 
encountered at 998 (62+28). F3's content is added to the dbus data in the 
alu shifted, along with Q, and written into the ram yielding 146.5 
(62+67.5+17) for the second end point. The alu output is sent to the zbus 
at 131.5 (624+67.5+2) and to the third end point, the V register at 136.5. 
Seven bits of the dbus are compared to seven bits of the zbus and sent to 
the fourth end point, IND7, at 146 (from zg at 131.5 + 14.5). The zbus is 
sent to the sbus unshifted at 143.5 (131.5412). From there the fifth end 
point (H) receives the sbus at 148.5. The sixth end point (ADRB) receives 
the sbus (148.5) at 159.9. The last end point is the next firmware address 
at 133.5 (68.5+65). Thus, loading ADRB is the longest path and with the 
addition of 10% (175.8) requires, the longest gear or a VL “box”. 
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THE FIRMWARE DEVELOPMENT FACILITY 


ea 


This appendix contains a description of the firmware development 


facility available for use with the 32-bit Custom Processor. The appendix 
is divided into three parts: 


4 
[ 
uy 
oe @ 


A general overview 
The menu 
A description of each menu item 


The Firmware Development Facility (FDF) is an equipment which makes 


firmware, coded and assembled under RIL, easy to checkout. The FDF 
consists of: : - 


A separate five card cage with an independent power supply 


A processor board with a Z88 processor (BF4RMP) 
A SILO board with a 4896 location SILO (BF4TFU) 


A 16,584 by 128 location control store PROM substitute (BF4CMX) 
including four memory array daughter boards (BS4CS4) 


A terminal/keyboard unit (e.g., 7300) 
Appropriate interconnecting cables 


Once the firmware has been tested and “burnt” into PROMs, the FDF - 
equipment listed above is no longer required and is never shipped to the 
end-user. The resulting CUP product connects to the MEGABUS System Bus 
through the Custom Memory Subsystem and the Custom MEGABUS Adapter unit. 


Figure A-1 is a diagram of the interconnections among the elements 
which comprise a firmware checkout “test bed”. 


\ 
[ 
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! 1 1 
[ a: Cables (2) CUP to SILO (04910282-001, 64918263-001 ) 
7 : Cable (1) SILO to 286 (94910236-001 ) 


c: Cable (1) Z8®8 to MEMORY (60128806-001 ) 

d: Cables (4) CUP to MEMORY (84910294-601 ) 

e: Cable (1) Z88 to TERMINAL (60156745-001) for RS232 
(68156675-9801) for RS422 
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COMMAND 


PBLK 


nPREV 


nSCAmocx 


nSCDxxxxxxxx 


LEFT ARROW 
RIGHT ARROW 
DOWN ARROW 
UP ARROW 


DISPLAY 
Summary of commands 


Silo location: 
-n WyVY = ZZ7ZZZzZzz 
where n = silo offset from stop point, in decimal 
(@ ~ 4095+, default m = current value) 
yyyy = firmware address 
ZzZzZzZzzzz = content of zbus at that address = 


Next 23 locations in SILO 
If offset of 6 is reached, “THE END" is displayed. 


Next n locations in SILO 
(n=1 ~- 4000; default = 1) 
If offset of 9 is reached, “THE END” is displayed. 


Previous 23 locations in SILO 
If offset of 4089 is reached, “THE END” is displayed. 


Previous n locations in SILO 
(n=1 - 4000; default = 1) 
If offset of 4088 is reached, “THE END” is displayed. 


Scan SILO for a firmware address = xxxx. 
Start scanning at an offset of -n (default = 4008). 
Display each match until either: 
an offset of zero is reached ("THE END® is displayed) or 
23 matches have occurred (hitting the space bar will 
display the next set of matches; hitting any other 
key will execute that command. ) 


Scan SILO for a data = xxxxxerxez. 


Start scanning at an offset of -n (default = 4066). 
Display each match until either: 


an offset of zero is reached ("THE END" is displayed) or 
23 matches have occurred (hitting the space bar will 
display the next set of matches; hitting any other 
key will execute that command. ) 
same as PREV | 
same as NEIT 
same as NBLEK 


same as PBLE 
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A ADRA=xxxxxxxx ADRB=xxxxxxxx ADRP=xxxxxxxx PHST=xxxxxxxx 
AA ADRA=xxxxxxxx 
AB ADRB=xxxxxxxx 
AP ADRP =xxxxxxxx 
: F Fo/8 F1/9 F2/A F7/F 
‘ SAMAK  XKKXEKEE UKE eae XXXXRNKN 
| COOS5GOOOSK XEKEKKKeXe soo cee xXXXXKXKXNK 
- Fn F register #n where n = @ through F (alterable by = 
, followed by input data) 
: Fn=XXxxXxxxxx 
H H register (alterable by = followed by input data) 
H=xxxxxxxx 
I Input registers and syndrome 
INRA=xxxxxxxx INRB=xxxxxxxx SYND=xxxexxxxx 
| Mn : Main memory location fn: (n = 6 through FFFFFFFF) 
q Mn = xXxxxxxxx 
Y Note: If location #n is nonexiestent or otherwise 
-inaccessible, the value “xxxxxexxx" displayed 
is the current content of register OUTR. 
No error indication is given. 
M. Main memory location most recently i a ala 
| Min = soramoonor 
¥ [ M+ Next doubleword in main memory: 
: Mn=xxxxxxxx 
Nee 
M- Previous doubleword in main memory: 
[ Mn=xxxxxxxx 
OP. OP=xxxx RBER’RAR=xxxx Izbbbbbbbbbbx 
; OP = OPA, OPB, OPC, OPD (1 hex digit rie ee 
RBR'RAR = RBR (1 digit), RARH (1 a a aioe (2 digits) 
I = Indicators ® through 9 (10 bits 
Indicators 10 through 13 (1 digit) 
PB Procedure bytes (right justified) 
PB=xxxx 
PH | PCTR history: 
PHST=xxxxxxxx 
Q Q register (alterable by = followed by input data) 
Q=xxxxxxxx 
: [ CUSTOM MEMORY SUBSYSTEM TECHNICAL DESCRIPTION PAGE A-4 
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R RO/8 R1/9 R2/A | R7/F 

SST xxxxxxxrx XXXXXXEE eee XXX XSI KIC 

> SOS CSCO 4 > © SS SSC OC > SSO COO S eee > SSS CSCC 


ARAM specified by n where n may be 900 through FFF 
(Alterable by = followed by input data) 
Rn =xXxxxxxxx 


R. ARAM location most recently displayed: 
: Rn=xxxcxexxxx 


- 


B 


R+ Next location in ARAM: 
: Rn=xxxxxxxx 


Stack register: 
S=xxxxxxxx 


n 


Vv V register 
V=xxxxxxxx 
=xXxxxxxxx Alter most-recently-displayed “alterable”" register 


to equal xxxxexxxx. (Alterable registers are: 
AA, AB, AP, Fn, H, Mn, M+, M-, Q, Rn, R+, R-) 


Define "EPILOG", a list of preselected commands which 
will be executed when any STOP is encountered. 
Format: - 

: COMMAND, COMMAND, COMMAND, etc. 
No blanks allowed between a comma and the next command. 
88 characters maximun. 
see also \,/.*, and ~ keys. 


[ 
[ 
[ 


* Display EPILOG and allow corrections. 
see also \, /, *, and ~ keys. 


Retrieve EPILOG #n (n = 2 through 6) 


| 
* 


n*S Save current EPILOG as EPILOG #n (n = 2 through 6) 
/ Skip next character of EPILOG 
\ Skip previous character of EPILOG being corrected 


Insert blank into EPILOG being corrected 


~7? 


Delete character of EPILOG being corrected 


nGOm Repeat previous m EPILOG commands n times 


[ (m,n=1 through 9) 
&  . y———-~—pisplay all-active Breakpoints 


i Byyyy:z Specify Breakpoint at firmware address = yyyy 
[ z = D: Disable capturing of history in.SILO 
z = E: Enable capturing of history in SILO 
2 = H: Address Halt not exclusive of D or E 


ByyyYy Clear Breakpoint at firmware address = yyyy 


NOTES: 


1 - Address is specified by last 14 bits of yyyy. 
2 - Breakpoints are armed only if command 
RONB or RUNL is used. 
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CLER Clear display screen (not breakpoints, addresses, etc) 

E Execute (current) EPILOG 

FWRAM CUP uses firmware in external RAM 


State appears on line 25 


FWPROM CUP uses firmware in PROMs (mounted on CUP boards) 
‘ State appears on line 25 


INIT Generate a Master Clear in the CUP. 
[ctl-clear] Breakpoints are left in the state they were in. 


JOCK Transfer firmware control to address xxxx 
nRUNB Place CUP in RUN mode, prepared to stop after the nnn-th 
[F6 } occurrence of a breakpoint halt. Default n = 1. 


The contents of the EPILOG-preselected registers will 
then be displayed. 


RUNG Place CUP in RUN mode, propared to stop aat the first 
[Fs] occurrence of a breakpoint halt, or the writing of the 
n-th SILO entry. (default = 4880) 
The contents of the EPILOG preselected registers will 
then be displayed. 


RUNN Place the Cup in RUN mode, and continue in that mode until 
(Transmit ) the "STOP" or "INIT" is actuated. 


nSTEP Cause CUP to execute nnn firmware steps (default n = 1). 
(F4) | 


[ STOP Put the CUP in STOP mode. The contents of the 

, (F2] EPILOG-preselected registers will then be displayed. 

| Note: The only functions allowed when not in STOP mode 
[ are "STOP" and “INIT”. 


XS+ Enable the CUP to stop when the external signal fed into 
the FDF goes from the low state to the high state. 


xXS- , Enable the CUP to stop when the external signal fed into 
the FDF goes from the high state to the low state. | 


XSD | Disable external stop. 


4 oe aia present FDF screen display to hard-copy printer, 
attached. Line 25 status is included, but without 
underscores, intensity variations, blinks, etc. 
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APPENDIX A FIRMWARE DEVELOPMENT FACILITY 
P COMMAND MEANING (TO DISPLAY AND CHANGE WRITABLE FIRMWARE ARRAY) 
[ Cxxxx. Display location xxxx, packed format, ready to modify 
Cxomxx \ | Display location xxxx, by fields, with headings 
Cxxxx Display location xxexx, by fields 
‘ Redisplay in field format, with headings 
[ LEFT ARROW Move cursor to previous field, ready to modify 


RIGHT ARROW Move cursor to next field, ready to modify 
° Revert to packed format, ready to modify 
UP ARROW Move to previous location 

DOWN ARROW Move to next location 


LOAD Load firmware into RAM. . 3 
[F108] After this command, actuate INITIALIZE to clear the CUP. 
Line 25 will display “LOAD” until "INIT" is pressed. 


« 
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